Обсуждение: AW: [HACKERS] Proposed Changes to PostgreSQL

Поиск
Список
Период
Сортировка

AW: [HACKERS] Proposed Changes to PostgreSQL

От
Zeugswetter Andreas SB
Дата:
> 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


Re: AW: [HACKERS] Proposed Changes to PostgreSQL

От
Chris Bitmead
Дата:
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.