On Tue, Aug 20, 2002 at 11:28:32AM -0400, Tom Lane wrote:
> "Nigel J. Andrews" <nandrews@investsystems.co.uk> 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
