Re: Support for ResultSetMetaData.getTableName

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Kris Jurka <books(at)ejurka(dot)com>
Cc: David Goodenough <david(dot)goodenough(at)btconnect(dot)com>, pgsql-jdbc(at)postgresql(dot)org
Subject: Re: Support for ResultSetMetaData.getTableName
Date: 2007-08-27 05:31:16
Message-ID: 13835.1188192676@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

Kris Jurka <books(at)ejurka(dot)com> writes:
> The discussion was focused on the ability of the server to return the
> alias of a table as well as the base table name. Because getColumnName
> will return "b" for "SELECT a AS b FROM c AS d" we have decided that
> getTableName should return "d" instead of "c".

[ itch... ] Just looking at this again, I wonder whether that's going
in the wrong direction. What is the point of getTableName, if not to
find out a table name that is usable in other queries? I also notice
that the spec provides getSchemaName, which is sensible if one supposes
that the point of all this is to find out the actual table name, and is
completely nonsensical if the point is to find out the inherently
not-schema-qualified table alias.

I suggest that the following mapping might be more sensible:

getColumnName returns "a"
getTableName returns "c"
getSchemaName returns name of c's schema
getColumnLabel returns "b"

where the first three fail if the SELECT column isn't a simple column
reference, but getColumnLabel always works.

I'm not sure what the use-case is for finding out "d".

regards, tom lane

In response to

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message Kris Jurka 2007-08-27 05:53:12 Re: Support for ResultSetMetaData.getTableName
Previous Message Kris Jurka 2007-08-27 05:02:06 Re: jdbc problem