Re: getTableName
От | Matt Mello |
---|---|
Тема | Re: getTableName |
Дата | |
Msg-id | 3E345629.6040205@spaceship.com обсуждение исходный текст |
Ответ на | Re: getTableName (Dave Cramer <Dave@micro-automation.net>) |
Список | pgsql-jdbc |
Furthermore, you could have a select that calculates values that come from many different tables. A select is a transformation on data in the tables. The columns in a select can have an infinite number (well, lots, anyway) of relationships to the columns in the tables, especially when you consider that the resultset columns could be the output of formulas applied to 0-N different table columns. eg: select a as b, c*a as d, e+c as f, 3.14159 * 42 as j, 666 * b as k from foo as c3, bar as c2, pil as c1 where ... So, even IF that information were available, some columns in your resultset might come from 1, many, or no columns in the database. I'm not sure that what you want to do makes any sense in a real-world sort of way. However, it would make sense to map a resultset to a class IF that class generated the SQL to being with, or IF the developer of that class already knew what columns would be in the resultset. That is what we do. We define a SQL query (which is constructed by the code itself using SQL rules and table+column definitions, and also regression tested against a live DB before we release). That query's output is then associated with a class that knows what to do with it (how to display it, etc.). Hope this helps. Dave Cramer wrote: > select a as b, c as d, e as f from foo as c1. > > The backend is the only one that knows which table which came from. -- Matt Mello
В списке pgsql-jdbc по дате отправления: