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