Thread: Alterations to backend/client protocol

This question is directed at the developers of Postgres.
How open are you to changing the protocol between the backend and the client ?

I posted a question regarding finding the tables to which fields (from a query)
belong. The problem I have is that the only information I have is that the query
is a SELECT. The query is completely arbitrary and I have no idea what the
select contains (and cannot change it).
Is it possible to change the  protocol between the backend/client to include the
the table names (or some unique value allowing me get to the table name) ? (for
data that has come directly from the DB and a blank table name for functions
that are not directly represented in a DB table).
Perhaps an option upon connection to use the new protocol (so not all the other
clients that currently work with the existing protocol break).

I am, depending on how much effort this takes, willing to perform the
development myself, can you measure the effort ?

ThanksPhilip
--------------------------------------------------------------------------
Philip Shiels     E-Mail:Philip.Shiels@jrc.it      JRC Ispra, Italy, TP270
GIST:http://gist.jrc.it                              GEM:http://gem.jrc.it
Tutorial:http://gist.jrc.it:8080

Philip Shiels <philip.shiels@jrc.it> writes:
> Is it possible to change the protocol between the backend/client to
> include the the table names (or some unique value allowing me get to
> the table name) ?

A protocol upgrade is certainly possible --- I caused one to happen
myself for 6.4.  However it incurs a certain amount of pain all around,
since new clients won't talk to old servers.  I think there'd have to
be some discussion and hopefully a consensus about whether the proposed
new features are worth the trouble.

BTW, changing the backend's rules for making default column labels would
be a way to provide the same info without needing a protocol upgrade.
It might break some application-level client logic, however.  Offhand
I'm not sure which way would give fewer headaches.  But people have
complained for a long time that the current default labels aren't
informative enough, so I think you could probably sell them on a more
useful labeling scheme even if it did break a few old clients.

> I am, depending on how much effort this takes, willing to perform the
> development myself, can you measure the effort ?

Any changes needed in the protocol (see the protocol chapter in the
developer's guide) and libpq would be trivial enough.  I do not know
whether it is practical to get the information you want inside the
backend, however --- in particular, for queries involving joins,
I think that the data effectively comes from a "temporary table" that
is the joined relation.  Can you identify the ancestry of columns in
that temp table?  I dunno.

My guess is that it'd be less work and less impact on other Postgres
users to modify the queries you send in the first place...
        regards, tom lane