Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in - Mailing list pgsql-hackers

From Zeugswetter Andreas SB SD
Subject Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Date
Msg-id 46C15C39FEB2C44BA555E356FBCD6FA4961E52@m0114.s-mxs.net
Whole thread Raw
Responses Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
List pgsql-hackers
> "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.

So the idea is, that input functions take cstring type, and output functions
take the explicit type they are designed for ?
Is there anything that can be done vs that types only exist after the functions ?
e.g. create it in one tx with constraints deferred ? Or is that no issue ?

>  (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.

Yes, it is great that you will look into this !!
About the names, would it be good to use SQL99 reserved words ? (e.g. ROW for tuple)
nice url: http://developer.mimer.se/validator/sql-reserved-words.tml

count(*)         --> anynumeric  :-) (two flies with one strike)
NULL/NONNULL    --> null|nullvalue|anynull ? We only need this internally, no ?

Hard to say what is good for those names imho, don't like "anytype" :-(
(maybe even leave that opaque for now)

I like "cstring", "void" and "internal".
Maybe "anyarray" instead of "anyarraytype".
And I would prefer "row" instead of "tuple".

Andreas


pgsql-hackers by date:

Previous
From: Stephan Szabo
Date:
Subject: Re: Proposal: make "opaque" obsolete
Next
From: Tom Lane
Date:
Subject: Re: Proposal: make "opaque" obsolete