Re: libpq, PQdescribePrepared -> PQftype, PQfmod, no PQnullable - Mailing list pgsql-hackers

From Tom Lane
Subject Re: libpq, PQdescribePrepared -> PQftype, PQfmod, no PQnullable
Date
Msg-id 3874.1318175507@sss.pgh.pa.us
Whole thread Raw
In response to Re: libpq, PQdescribePrepared -> PQftype, PQfmod, no PQnullable  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Responses Re: libpq, PQdescribePrepared -> PQftype, PQfmod, no PQnullable  (Magnus Hagander <magnus@hagander.net>)
Re: libpq, PQdescribePrepared -> PQftype, PQfmod, no PQnullable  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> Florian Pflug  wrote:
>> I don't think the reply to a DESCRIBE message is currently
>> extensible, so we'd probably need to add a new version of the
>> message.
> Or a new protocol version.

Exactly --- this *would* require a protocol version bump.

>> That might be a rather tough sell, as least as long as there's
>> isn't a clear use-case for this. Which, unfortunately, nobody has
>> provided so far.
> Yeah.  It would be nice to see at least one use case.  The only
> comment I recall is a vague suggestion that that people might want to
> select data from a table and infer table attributes from the result
> set metadata.  That seems marginal.

Yes.  We need a pretty convincing use-case to seriously consider such a
thing.

> Yeah, it wouldn't be hard to produce a long list of things which
> would take about the same effort which seem more beneficial to me. 
> It's a matter of whether this is causing someone enough bother to
> want to devote the resources to changing it.

The problem with something like a protocol bump is that the coding
required to make it happen (in the backend and libpq, that is) is only a
small part of the total distributed cost.  So even if someone stepped up
with a patch, it'd likely get rejected outright, unless there's
significant community buy-in to the need for it.

I agree with Kevin's comment that the right thing to be doing now would
be to be keeping a list of things we might want to change the protocol
for.  It's just about certain that no single element on that list will
be sufficient reason to change, but once there are enough of them maybe
we'll have critical mass to do them all together.

(Actually, isn't there such a page on the wiki already?  Or a subsection
of the TODO list?)
        regards, tom lane


pgsql-hackers by date:

Previous
From: Kohei KaiGai
Date:
Subject: Re: [v9.2] Fix Leaky View Problem
Next
From: Tom Lane
Date:
Subject: Re: libpq, PQdescribePrepared -> PQftype, PQfmod, no PQnullable