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

From: "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Justin Clift" <justin(at)postgresql(dot)org>, "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au>, "Vince Vielhaber" <vev(at)michvhf(dot)com>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Date: 2002-08-21 16:32:48
Message-ID: 46C15C39FEB2C44BA555E356FBCD6FA4961E58@m0114.s-mxs.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Zeugswetter Andreas SB SD 2002-08-21 16:41:54 delay beta ? (was: RE: @(#)Mordred Labs advisory 0x0003: Buffer overflow in)
Previous Message Bruce Momjian 2002-08-21 16:25:07 Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in