Re: Support for DatabaseMetadata: getCatalogName, getTableName,

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Ken Johanson <pg-user(at)kensystem(dot)com>
Cc: pgsql-jdbc(at)postgresql(dot)org, Kris Jurka <books(at)ejurka(dot)com>
Subject: Re: Support for DatabaseMetadata: getCatalogName, getTableName,
Date: 2007-01-05 05:28:52
Message-ID: 10251.1167974932@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

Ken Johanson <pg-user(at)kensystem(dot)com> writes:
> Kris Jurka wrote:
>> The previous discussion I cited was referring to getColumnName and how
>> it really should be referring to the alias of a result, not the column
>> itself. That is for "SELECT a AS b FROM c AS d" should return "b" for
>> getColumnName(1). If we accept that as true then it follows that
>> getTableName(1) should return "d", not "c".

> Understood now, thanks. I agree/vote this is the best spec
> interpretation/behavior (for its lack of a 'getTableLabel').

Urm ... I might agree with that, except for its signal lack of usefulness.
What is the point of knowing the table alias? The
underlying-table-and-column names have some possible usefulness for
issuing updates against the underlying tables, but what the heck are you
going to do with "d" here? If the application understands the query
(which it itself issued, don't forget) well enough to understand what
"d" conveys, why wouldn't "b" be at least as useful?

I think you're letting a narrow reading of some admittedly-badly-written
spec text get the best of you.

regards, tom lane

In response to

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message Ken Johanson 2007-01-05 07:16:46 Re: Support for DatabaseMetadata: getCatalogName, getTableName,
Previous Message sbaskar 2007-01-05 04:25:05 PgSQL Monitoring( Please let me know the table details )