From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | philip(dot)shiels(at)jrc(dot)it |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] Alterations to backend/client protocol |
Date: | 1999-02-23 15:36:53 |
Message-ID: | 11380.919784213@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Philip Shiels <philip(dot)shiels(at)jrc(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Brian P Millett | 1999-02-23 15:40:36 | postmaster failure with 2-23 snapshot |
Previous Message | Brian P Millett | 1999-02-23 15:32:40 | postmaster fails with 2-23 snapshot |