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