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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: libpq, PQdescribePrepared -> PQftype, PQfmod, no PQnullable
Дата
Msg-id 3874.1318175507@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: libpq, PQdescribePrepared -> PQftype, PQfmod, no PQnullable  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Ответы Re: libpq, PQdescribePrepared -> PQftype, PQfmod, no PQnullable
Re: libpq, PQdescribePrepared -> PQftype, PQfmod, no PQnullable
Список 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 по дате отправления:

Предыдущее
От: Kohei KaiGai
Дата:
Сообщение: Re: [v9.2] Fix Leaky View Problem
Следующее
От: Tom Lane
Дата:
Сообщение: Re: libpq, PQdescribePrepared -> PQftype, PQfmod, no PQnullable