Обсуждение: Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in

> >>> Hard to say what is good for those names imho, don't like
> >>> "anytype" :-(
> >>
> >> How about "any"?  It's a reserved word per SQL99, I think.
>
> > I would actually stick to opaque in that case, already used in other db's.
>
> I want to change the name because (a) we are changing the semantics,
> (b) we can't throw notices for opaque if we keep it as a valid choice.

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.
If it is not all types I would rather use a more restrictive name (nulltype
/ anynumeric).
Imho opaque is missing a runtime type info, like a descriptor,
and thus only "pass by value" could not be allowed anymore.

I guess I must sleep over this, not convinced about depricating opaque yet :-)

> I meant that if the one name is "any", then making the other "anyarray"
> (ie, both without "type" on the end) is consistent.

Ah, good.

Andreas

On Tue, 2002-08-20 at 16:46, Zeugswetter Andreas SB SD wrote:
> > >>> Hard to say what is good for those names imho, don't like 
> > >>> "anytype" :-(
> > >> 
> > >> How about "any"?  It's a reserved word per SQL99, I think.
> > 
> > > I would actually stick to opaque in that case, already used in other db's.
> > 
> > I want to change the name because (a) we are changing the semantics,
> > (b) we can't throw notices for opaque if we keep it as a valid choice.
> 
> 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.

Erm.. count(*) <- * is literally anything.

"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.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