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@postgresql.org [mailto:pgsql-hackers-
> owner@postgresql.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@bellsouth.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