Re: Support for ResultSetMetaData.getTableName
От | Tom Lane |
---|---|
Тема | Re: Support for ResultSetMetaData.getTableName |
Дата | |
Msg-id | 13835.1188192676@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Support for ResultSetMetaData.getTableName (Kris Jurka <books@ejurka.com>) |
Ответы |
Re: Support for ResultSetMetaData.getTableName
|
Список | 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 по дате отправления: