Re: Roadmap for FE/BE protocol redesign

It's rumoured that Tom Lane once said:
> "Dave Page" <dpage(at)vale-housing(dot)co(dot)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.)

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