On Tue, Aug 20, 2002 at 11:28:32AM -0400, Tom Lane wrote: > "Nigel J. Andrews" <[EMAIL PROTECTED]> writes: > > But going back to the idea that it seems that the only problem being > > publicised in the 'outside world' is the cash_out(2) version can we > > not do the restriction on acceptable input type in order to claim that > > the fix? > > Totally pointless IMHO, when the same problem exists in hundreds of > other functions. Also, there really is no way to patch cash_out per se; > the problem is a system-level problem, namely failure to enforce type > checking. cash_out has no way to know that what it's been passed is the > wrong kind of datum. > > Basically, we've used "opaque" as a substitute for accurate type > declarations; that's got to stop.
Hmm, are there _any_ cases where it's appropriate to call an 'opaque' function directly from user code? cash_out() and it's kin are type output functions that are called under controlled conditions, with backend controlled parameters. Trigger functions also are called with backend controlled parameters. Is there a 'hack' fix that doesn't allow opaque returning functions in user-defined locations? Ross ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
