Re: libpq, PQdescribePrepared -> PQftype, PQfmod, no PQnullable

"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)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