Re: Support for ResultSetMetaData.getTableName
От
Kris Jurka
Тема
Re: Support for ResultSetMetaData.getTableName
Дата
Msg-id
Pine.BSO.4.64.0708270140030.23186@leary.csoft.net
Ответ на
Список
Дерево обсуждения
Support for ResultSetMetaData.getTableName David Goodenough <david.goodenough@btconnect.com>
Re: Support for ResultSetMetaData.getTableName Kris Jurka <books@ejurka.com>
Re: Support for ResultSetMetaData.getTableName Tom Lane <tgl@sss.pgh.pa.us>
Re: Support for ResultSetMetaData.getTableName Kris Jurka <books@ejurka.com>
Re: Support for ResultSetMetaData.getTableName David Goodenough <david.goodenough@btconnect.com>
On Mon, 27 Aug 2007, Tom Lane wrote: > 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 tried that back here: http://archives.postgresql.org/pgsql-jdbc/2004-07/threads.php#00314 and continuing here: http://archives.postgresql.org/pgsql-jdbc/2004-08/threads.php#00008 This message demonstrates that many other drivers do Column Name/Label in a different way: http://archives.postgresql.org/pgsql-jdbc/2004-08/msg00012.php So while I agree with you that the above suggestions make sense from a blank slate, we can't do this without causing problems. It seems people would like us to fallback from our position of table and schema returning aliases, which while inconsistent, is certainly more useful at this point in time. Kris Jurka
В списке pgsql-jdbc по дате отправления