"Tom Lane" <[EMAIL PROTECTED]> writes: > Gregory Stark <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
