Re: Support for DatabaseMetadata: getCatalogName, getTableName,
От | Ken Johanson |
---|---|
Тема | Re: Support for DatabaseMetadata: getCatalogName, getTableName, |
Дата | |
Msg-id | 459DFB5E.9030701@kensystem.com обсуждение исходный текст |
Ответ на | Re: Support for DatabaseMetadata: getCatalogName, getTableName, (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-jdbc |
Tom Lane 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, Agreed. but what the heck are you > going to do with "d" here? you can (as you know) have multiple table aliases on the same table, where for example 'd' might represent a relation value to c. For example a manager 'd' over a employee 'c': select c.firstName, d.firstName from contacts as c, contacts as d where c.bossId=d.pk and d.role=... With the table name alias I can tell which rows are bosses or subordinates (without needing to know/maintain column ordinality, or otherwise just by doing a `select * from..`). The real world use I have is similar to above except that I add in another table for one to many relations (multiple bosses or trainers, etc), and don't really use the bossId field -- it exemplifies the idea here though. For low level and efficient data retrieval this this is the very simplest and most elegant SELECT methodology I've come across - just select * from [joined tables], and a diver can build hierarchal hashtables, or instead a flat one with (albeit stringbuffer-built) keys (tbl.get("boss.firstName")) 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? Yes, but one isn't in the spec as you stated. 'd' seems the more useful to me. And if it defaults to the real name in absence of an alias, that seems logical and all-serving also.
В списке pgsql-jdbc по дате отправления: