On Thu, 4 Jan 2007, Ken Johanson wrote:
>> Right now we don't have the information to return "d" and so we must
>> always return the empty string. Getting the base column and table names
>> seems more useful but does not appear to be what the javadoc and spec
>> imply as the behavior of the standard API methods.
>>
>
> So to be sure, this (literal and alias name differentiation) actually is not
> being provided via the current server V3 protocol or server?
What we get now in the V3 protocol:
1) the column name which may be an alias but we don't know if it came from
an alias or not, consider SELECT a AS a. If we get "a" we don't know if
it was aliased or not.
2) The underlying table's oid which can be used to lookup it's name and
schema.
3) The underlying column's number in the table which can be used to lookup
its name.
No information on a table alias is available.
> If so, does anyone know off hand if V3 is somehow extensible; i.e can we add
> in metadata without breaking apps or major version?
>
No the RowDescription message is fixed:
http://www.postgresql.org/docs/current/static/protocol-message-formats.html
> Again, just trying to get an idea of how near or far off this may be. I think
> there are several high level object persistence wrappers out there that
> depend (right or wrong) on table names/aliases to reconstitute objects from
> selects and natural/inner joins.
>
It's a ways off and even if it was working you have to think about things
like self joins and calculated results. What can a tool do with these?
SELECT t1.col, t2.col, 1+3 FROM tab t1, tab t2 WHERE t1.a = t2.b;
And app would need some serious smarts to unravel this sort of thing.
Kris Jurka
