Re: Roadmap for FE/BE protocol redesign
От | Dave Page |
---|---|
Тема | Re: Roadmap for FE/BE protocol redesign |
Дата | |
Msg-id | 50119.80.177.99.193.1047374707.squirrel@ssl.vale-housing.co.uk обсуждение исходный текст |
Ответ на | Re: Roadmap for FE/BE protocol redesign (Bruce Momjian <pgman@candle.pha.pa.us>) |
Список | pgsql-hackers |
It's rumoured that Bruce Momjian once said: > Tom Lane wrote: >> "Dave Page" <dpage@vale-housing.co.uk> writes: >> > What about the addition of pg_attribute.attrelid & >> > pg_attribute.attname/attnum in RowDesription messages to identify >> > the underlying attribute (where appropriate)? >> >> Well, we can talk about it, but I still think that any frontend that >> relies on such information is broken by design. (And if that means >> the JDBC spec is broken, then the JDBC spec is broken.) >> >> Just to start with, if I do "SELECT * FROM view", am I going to see >> the info associated with the view column, or with the hypothetical >> underlying table column? (Actually, didn't I already make a list of a >> bunch of ways in which this concept is underspecified? AFAIR, you >> didn't suggest answers to any of those questions ... but we need >> answers to all of them if we are going to implement the feature.) > > I was willing to add a hack to enable default column labels to be > "table.column" --- that seemed like the least obtrusive. That would help, but not in the cases that cause the most grief - for example when the column has been aliased in the original query - that should override the label of course, but then we still need to parse the SQL at the client to figure out what's going on. Regards, Dave.
В списке pgsql-hackers по дате отправления: