Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in - Mailing list pgsql-hackers

From Zeugswetter Andreas SB SD
Subject Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Date
Msg-id 46C15C39FEB2C44BA555E356FBCD6FA4961E55@m0114.s-mxs.net
Whole thread Raw
Responses Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in  (Rod Taylor <rbt@zort.ca>)
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> >>> 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


pgsql-hackers by date:

Previous
From: Neil Conway
Date:
Subject: Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL (fwd)
Next
From: Vince Vielhaber
Date:
Subject: @(#)Mordred Labs advisory 0x0004: Multiple buffer overflows in PostgreSQL. (fwd)