"Dave Page" <[EMAIL PROTECTED]> 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.)
The problem Dave is suggesting this as a first attempt at a solution for is that with ODBC, a frontend (i.e. OpenOffice) asks the ODBC driver which columns are NULLable, etc. And the ODBC driver is getting the info wrong, then passing back the incorrect info.
So, when a person goes to insert a row into a table with a SERIAL/SEQUENCE based column, OpenOffice has been told the column isn't NULLable and forces the user to enter a value. Voila, it doesn't work with sequences. :(
It's likely possible to add to the ODBC driver some way of getting the info right, but Dave is also looking for a way of making this easier into the future for similar problems. i.e. Let the database explicitly have info about what each column can do.
That's my understanding of it anyway.
:-)
Regards and best wishes,
Justin Clift
regards, tom lane
-- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives?
http://archives.postgresql.org
