Dave Cramer <[EMAIL PROTECTED]> writes:
> So for a "select a, b, a+b as sum from c" returns c.a, c.b, ?table?.sum

This might be something to consider as part of the planned protocol
overhaul.  We cannot simply change the returned column names --- at
least not without breaking a lot of application code.  But if we
return table name (and schema name too!) as separate fields of the
'T' message, and make them accessible through new PQfoo accessor
functions, then no existing applications would break.

But there are more than a few definitional issues to be settled before
you'll convince me this idea is fully baked.  Some things that come to
mind immediately:

What happens with views?  Given
        create view v as select col as vcol from tab;
        select vcol from v;
are you expecting to get back "v.vcol"?  Or "tab.col"?

What happens with FROM-clause aliases?  Supposing tab really has a
column "col", what do you expect to see from
        select * from tab AS a(t1), tab AS b(t2) WHERE ...
You could make a case for either "tab.col, tab.col" or "a.t1, b.t2"
(in the latter case, you can't realistically return a schema name).
But you will probably break existing code if you do the former, since
currently the output columns are labeled t1, t2.

What happens with join aliases (similar issues to above)?

Do you think
        select col as foo from tab
should return "tab.foo", or just "foo"?  I'd lean to the latter;
"tab.foo" seems awfully misleading.  Or maybe you're wanting it
to ignore the AS and return "tab.col"?  Don't think that will fly.

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Reply via email to