| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at> |
| 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:56:23 |
| Message-ID: | 26433.1029948983@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at> writes:
>> 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 ?
Huh? It'll be perfectly visible.
There is one little problem with calling it ANY, it turns out: that word
is fully reserved in our parser (and trying to make it less reserved
creates reduce/reduce conflicts). So unless we go back to "anytype"
you'd have to quote the name, eg
create function foo("any") returns ...
I do prefer using "any" because that's what we have historically used
in CREATE AGGREGATE, but maybe the keyword conflict will be too
annoying.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2002-08-21 16:59:50 | Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in |
| Previous Message | Justin Clift | 2002-08-21 16:42:38 | Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in |