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 ?
Thanks
Philip
--------------------------------------------------------------------------
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
Import Notes
Reply to msg id not found: YourmessageofTue23Feb1999161836+010036D2C6CC.92534F2E@jrc.it | Resolved by subject fallback