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

Поиск
Список
Период
Сортировка
От Zeugswetter Andreas SB SD
Тема Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Дата
Msg-id 46C15C39FEB2C44BA555E356FBCD6FA4961E58@m0114.s-mxs.net
обсуждение исходный текст
Ответы Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Список pgsql-hackers
> > In my paper I use C functions that take "any tuple".
> > I do not yet see how I can do that without opaque if we don't
> > have a "row" but only a "trigger" type.
>
> For that you would have to use "any", at the moment.  This would give
> you the same amount of type safety you have with "opaque", ie, none.

I would have to use some pg_proc magic to make "any" appear there,
since the plan was to not make it visible at the sql level, no ?
If you do, you would also have to throw the notice for "any".

Again, I think leaving "any" be "opaque" and throwing the warning NOTICE
would be better. I do not think there is enough time to really see through
the implications of restricting opaque already in 7.3, (at least for me :-)

> We could talk about adding more pseudotypes that are geared to
> requirements not existing in the standard set of functions ...
> but I'm going to concentrate on those first.

Yes, certainly a lot of work.

Andreas


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in
Следующее
От: "Zeugswetter Andreas SB SD"
Дата:
Сообщение: delay beta ? (was: RE: @(#)Mordred Labs advisory 0x0003: Buffer overflow in)