Re: Libpq PGRES_COPY_BOTH - version compatibility

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Libpq PGRES_COPY_BOTH - version compatibility
Дата
Msg-id 9182.1301199614@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Libpq PGRES_COPY_BOTH - version compatibility  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Libpq PGRES_COPY_BOTH - version compatibility  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Jan 3, 2011 at 6:55 AM, Magnus Hagander <magnus@hagander.net> wrote:
>>> ISTM that the correct fix is to increment to protocol version number to
>>> 3.1 and send PGRES_COPY_OUT if the client requests version 3.0. �That's
>>> what the version numbers are for, no?

>> It still won't help in my situation though - I need to know what
>> version of the libpq headers I have in order to even be able to
>> *compile* the program. At runtime, I could check against the server
>> version, and get around it.

> This is listed on the open items list as "raise protocol version
> number", but the above discussion suggests both that this might be
> unnecessary and that it might not solve Magnus's problem anyway.

> What do we want to do here?

I'm not in favor of bumping the protocol version number for this.
Magnus is correct that that'd be the right thing to do in an abstract
sense; but we haven't bumped the protocol version number since 7.4,
and so I have no faith that clients will behave sensibly.  I think
we'd be much more likely to break things than to accomplish anything
useful.  Given the small fraction of client programs that will care,
and the fact that a protocol bump doesn't fix the whole issue anyway,
working around it on the client side seems much the best compromise.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: DO hint update?
Следующее
От: 3dmashup
Дата:
Сообщение: Re: would hw acceleration help postgres (databases in general) ?