Ola Sundell <ola@miranda.org> writes:
> On Thu, 5 Jul 2001, Peter Eisentraut wrote:
>> These functions are fundamentally flawed, because it's impossible to
>> determine the table name that a result column came from, except in the
>> most simple cases in which case you don't need these functions.
> I disagree. You can either parse the query at the client side, which is
> flawed, imo, or you can make the backend send the information along with
> the rest of the Field metadata.
Peter's point is that in the general case there is no reasonable answer.
A few counterexamples:
select a.f1 + b.f2 as sum from a,b where ...
Which table would you like to say the output column "sum" is from?
select * from a inner join b using (id);
This query will join a and b on "a.id = b.id". Per SQL92, the output
will have only one column named id, not two. Which table would you like
to say the column came from?
select f1 from a UNION select f2 from b;
The usual question.
> One thing you might want to consider,
> though, is that the information is necessary for the
> UpdateableResultSets. How, else, are you going to execute the updates?
While I haven't read the JDBC spec, I'd have to guess that the entire
notion of an updateable result set is defined only for a very small
subset of possible SELECT queries --- small enough that deducing the
requested information is pretty trivial. In particular, I don't
believe that the notion of an updateable result set can be considered
well-defined for *any* query that involves a join. Therefore there is
only one table in the FROM clause, and deducing the correct result
for getTableName() is trivial.
regards, tom lane
