Re: Request for qualified column names

Well, certainly the driver could parse the sql and extract what it
thinks is the table name. It just seems quite foreign to me to have a
database engine go through the motions of determining column location
and have ready access to all the metadata for all the columns in a
resultset and then intentionally leave all that out of the FE/BE. Now,
for us driver writers, if I have a select statement that has 20 columns
I will need to extract the tablename myself (and hope I got it right)
and then execute 20 separate queries to the database in order to
implement any type of schema generation. I guess I don't understand
this when just a few extra bytes in the RowDescriptor message would have
fixed all this.

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: Monday, January 27, 2003 9:21 AM
> To: Reggie Burnett
> Cc: 'Dave Cramer'; 'PostgreSQL Hackers Mailing List'
> Subject: Re: [HACKERS] Request for qualified column names
>
> "Reggie Burnett" <rykr(at)bellsouth(dot)net> writes:
> > 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.
>
> That seems quite pointless. You hardly need the backend's help to
> determine which column belongs to which table in a single-table query.
> AFAICS this facility is only of interest if it does something useful
> in not-so-trivial cases.
>
> regards, tom lane
>
> ---------------------------(end of
broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org