Re: Request for qualified column names
От | Reggie Burnett |
---|---|
Тема | Re: Request for qualified column names |
Дата | |
Msg-id | 00c301c2c61b$0f989630$c600a8c0@endeavor обсуждение исходный текст |
Ответ на | Re: Request for qualified column names (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Request for qualified column names
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: