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-20 20:56:00 |
Message-ID: | 7365.1029876960@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:
> Hmm, "any" would sound like it is the same as opaque. Would "any" really be
> all allowed types ? I think we would want to eliminate that altogether.
Do you plan on eliminating the COUNT() aggregate, then?
> Imho opaque is missing a runtime type info, like a descriptor,
> and thus only "pass by value" could not be allowed anymore.
AFAICS it's only useful for functions that only care whether their
argument is NULL or not, and don't inspect its value. But that just
happens to describe COUNT, as well as nullvalue/nonnullvalue.
I don't really think that using ANY instead of OPAQUE for this purpose
will affect users, because they will never be declaring any functions
that would legitimately take ANY, much less return ANY (the latter
probably makes no sense at all). It seems to me that COUNT, nullvalue,
and nonnullvalue pretty much cover the spectrum of what you can usefully
do with only an isnull bit to look at...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Frank Wiles | 2002-08-20 20:57:05 | Re: @(#)Mordred Labs advisory 0x0004: Multiple buffer overflows inPostgreSQL. (fwd) |
Previous Message | Dann Corbit | 2002-08-20 20:54:53 | Re: @(#)Mordred Labs advisory 0x0004: Multiple buffer overflows inPostgreSQL. (fwd) |