Re: SQL feature requests

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: "Peter Eisentraut" <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>, "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>, "Josh Berkus" <josh(at)agliodbs(dot)com>
Subject: Re: SQL feature requests
Date: 2007-08-24 15:12:13
Message-ID: 29952.1187968333@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> ... 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.

Well, if you're using client-side code that depends on access by name
rather than field position, you definitely have to put in AS clauses.
Even if we did generate distinct names, a client couldn't rely on
knowing in advance what they'd be.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2007-08-24 15:24:53 Re: Final background writer cleanup for 8.3
Previous Message Tom Lane 2007-08-24 15:08:55 Re: Buildfarm failures MSVC