"Tom Lane" <tgl@sss.pgh.pa.us> writes:
> Gregory Stark <stark@enterprisedb.com> writes:
>
>> 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.
That's why I got tied up trying to describe a scenario where you wouldn't have
to rely on knowing in advance what they would be. If you're running some kind
of reporting tool it could let the user type in arbitrary queries and then
look at what names are returned from the describe message to put in its column
headings.
If such a tool was written in perl using fetchrow_hashref I think it would end
up receiving only one of each distinct column name. Whereas it should be able
to depend on receiving all of them with distinct names, even if it won't know
what those names will be in advance.
If it's written to use arrays and column positions then it would still work
properly though. And we haven't seen any real complaints.
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com