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 по дате отправления: