Dave Cramer <dave@fastcrypt.com> 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? Givencreate 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 fromselect * 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 thinkselect 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