> The SQL style is to use wordy descriptions of the operators
> meaning. "ONLY" fits well here because it describes its own meaning
> perfectly whereas to the unitiated, "*" is harder to guess at. While
> this change is an incompatibility I hope for those few people using
> inheritance they can accept the need to move forward without
> over-burden of backwards compatibility.

Might also allow the *, but do nothing with it, or maybe throw a
"deprecated" notice. 

> > SELECT *, studentid FROM person;
> NAME
> ----
> Fred
> Bill
> 
> NAME | STUDENTID
> ----------------
> Jim  | 23455    
> Chris| 45666

The above is incorrect, since the * already returns studentid, thus the
result 
of the above query should be:
> SELECT *, studentid FROM person;
NAME
----
Fred
Bill

NAME | STUDENTID | FACULTY | STUDENTID
--------------------------
Jim  | 23455     | Science | 23455
Chris| 45666     | Arts      | 45666
    
> Also there should be an settable option that specifies that "*" should
> also return the normally ignored columns of oid and classname. This is
> so that OO programs that embed SQL into them also get back the oid and
> classname which are required for the behind the scenes implementation
> of an ODMG client. Something like...

why don't they simply always 
select oid, classname, * from ...
The reason I suggest this is, because implementing joins to return the 
correct oid, classname seems very complex.

The rest sounds good to me :-)

Andreas

Thu, 3 Feb 2000 15:47:07 +0100 
Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
AW: [HACKERS] Proposed Changes to PostgreSQL
Zeugswetter Andreas SB wrote:

> > Also there should be an settable option that specifies that "*" should
> > also return the normally ignored columns of oid and classname. This is
> > so that OO programs that embed SQL into them also get back the oid and
> > classname which are required for the behind the scenes implementation
> > of an ODMG client. Something like...
> 
> why don't they simply always
> select oid, classname, * from ...
> The reason I suggest this is, because implementing joins to return the
> correct oid, classname seems very complex.

Because I envisage people using an ODBMS-ish interface and allowing
use of SQL queries. This infrastructure wouldn't work without oid and 
classname. Forcing always to add oid, classname would be
repetitive and error prone.

Fri, 04 Feb 2000 09:48:04 +1100
Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Re: AW: [HACKERS] Proposed Changes to PostgreSQL