Ola Sundell <[EMAIL PROTECTED]> 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

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Reply via email to