Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in

Поиск
Список
Период
Сортировка
От Zeugswetter Andreas SB SD
Тема Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Дата
Msg-id 46C15C39FEB2C44BA555E356FBCD6FA4961E52@m0114.s-mxs.net
обсуждение исходный текст
Ответы Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Список 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 по дате отправления:

Предыдущее
От: Stephan Szabo
Дата:
Сообщение: Re: Proposal: make "opaque" obsolete
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Proposal: make "opaque" obsolete