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

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

In response to

Browse pgsql-hackers by date

  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)