Re: Support for ResultSetMetaData.getTableName - Mailing list pgsql-jdbc

From Tom Lane
Subject Re: Support for ResultSetMetaData.getTableName
Date
Msg-id 13835.1188192676@sss.pgh.pa.us
Whole thread Raw
In response to Re: Support for ResultSetMetaData.getTableName  (Kris Jurka <books@ejurka.com>)
Responses Re: Support for ResultSetMetaData.getTableName  (Kris Jurka <books@ejurka.com>)
List pgsql-jdbc
Kris Jurka <books@ejurka.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

pgsql-jdbc by date:

Previous
From: Kris Jurka
Date:
Subject: Re: jdbc problem
Next
From: Kris Jurka
Date:
Subject: Re: Support for ResultSetMetaData.getTableName