
> The cash_out problem can't really be fixed until we do something about
> subdividing type "opaque" into multiple pseudo-types with more carefully
> defined meanings.  cash_out is declared cash_out(opaque) which does not
> really mean that it accepts any input type ... but one of the several
> meanings of "opaque" is "accepts any type", so the parser 
> doesn't reject cash_out(2).

Would it be possible to update the system tables, so that cash_out does not take
opaque but really takes type money ?
I mean the first thing cash_out does is PG_GETARG_CASH(0), so it really only copes 
with a money type.

I know the problem is that the cat chases its tail here, because of what comes first,
the type or the io functions. But couldn't this be overcome, at least for internal types ?

Andreas

Tue, 20 Aug 2002 18:36:58 +0200
"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in 
"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes:
> Would it be possible to update the system tables, so that cash_out does not take
> opaque but really takes type money ?

That is part of the solution, but only part: we have hundreds of
functions that take "opaque" because we don't currently have any way
to declare what they really take.  (In particular, all the typinput
functions are like that --- so fixing typoutput functions isn't plugging
even half of the gap.)

See my proposal to make "opaque" obsolete.

			regards, tom lane

Tue, 20 Aug 2002 14:50:00 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in 