"Tom Lane" <[EMAIL PROTECTED]> 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

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not
       match

Reply via email to