It's rumoured that Tom Lane once said: > "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.)
I don't know about JDBC, but ODBC could use it, and it would save a heck of a lot of pain in apps like pgAdmin that need to figure out if a column in an arbitrary resultset might be updateable. At the moment there is some nasty code in pgAdmin II that attempts to parse the SQL statement to figure out if the the resultset is updateable by trying to figure out the number of relations in the query, whether any of them is a view or sequence, whether there are any function calls or expressions in the attribute list and so on. It then has to try to figure out if there is a complete pkey in the resultset that can be used for the update, or whether it should attempt an update based on all existing values. That code is just plain nasty in VB. In pgAdmin III we've already mentioned stealing bits of the PostgreSQL parser. The addition of the base column identifier (the pg_attribute.oid would have sufficed, but I can live with attrelid, attname, or even nspnam, relname & attname or similar) would make this trivil, and allow interfaces like ODBC, JDBC, OLE-DB and Npgsql to gain easy access to any metadata they might require. > 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? The view. We don't care where the data originally came from, only where it came from as far as the query creating the resultset is concerned. Of course, updateable views would make this irrelevant anyway... (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 guess I must have missed that thread. Regards, Dave ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
