Re: Request for qualified column names

When talking about expressions,views, or any other construct that could
combine values from multiple tables I think it is reasonable to provide
null as the table name. Any one or any process requesting the table
name has to understand that not all SQL parameters have a base table
name. However, in the case where a single table is involved, table and
schema names should be available.

Reggie

> -----Original Message-----
> From: pgsql-hackers-owner(at)postgresql(dot)org [mailto:pgsql-hackers-
> owner(at)postgresql(dot)org] On Behalf Of Tom Lane
> Sent: Sunday, January 26, 2003 7:39 PM
> To: Dave Cramer
> Cc: PostgreSQL Hackers Mailing List
> Subject: Re: [HACKERS] Request for qualified column names
>
> Dave Cramer <dave(at)fastcrypt(dot)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? 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