Re: SQL feature requests - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: SQL feature requests
Date
Msg-id 87ps1d2lrq.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: SQL feature requests  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: SQL feature requests  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
"Tom Lane" <tgl@sss.pgh.pa.us> writes:

>             c) Otherwise, the <column name> of the i-th column of the <query
>               specification> is implementation-dependent and different
>               from the <column name> of any column, other than itself, of
>               a table referenced by any <table reference> contained in the
>               SQL-statement.
>
> Implementation-dependent is a term of art here: it means that each DBMS
> can do whatever the heck it wants.  (But note that we fail to meet (c)
> exactly, since we don't bother to generate names that are distinct ---
> but in practice no one seems to care about that.)

Actually I suspect there are people who get annoyed by it when they try to
reference a column by name in a client driver like DBI which allows that. 

Note that if you use something like fetchrow_hashref it will actually condense
out duplicate column names since it loads the row into a hash. So if you
you're writing a program which just wants to dump the record without
understanding it you probably load it into a hash and then dump the hash in
key=>value form. And that will cause some columns to be dropped in the output.

But those people probably just figure it was their own fault and put in
aliases in their queries.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Buildfarm failures MSVC
Next
From: Gregory Stark
Date:
Subject: Re: Final background writer cleanup for 8.3