Re: Request for comment on setting binary format output per session

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: Request for comment on setting binary format output per session
Дата
Msg-id CAHyXU0wkg2Gt03q_Xu=BSd3u7hh7X9BL1cd_menH=9Xxb2fkew@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Request for comment on setting binary format output per session  (Peter Eisentraut <peter@eisentraut.org>)
Ответы Re: Request for comment on setting binary format output per session  (Peter Eisentraut <peter@eisentraut.org>)
Список pgsql-hackers
On Wed, Oct 4, 2023 at 9:17 AM Peter Eisentraut <peter@eisentraut.org> wrote: 
I think intuitively, this facility ought to work like client_encoding.
There, the client declares its capabilities, and the server has to
format the output according to the client's capabilities.  That works,
and it also works through connection poolers.  (It is a GUC.)  If we can
model it like that as closely as possible, then we have a chance of
getting it working reliably.  Notably, the value space for
client_encoding is a globally known fixed list of strings.  We need to
figure out what is the right way to globally identify types, like either
by fully-qualified name, by base name, some combination, how does it
work with extensions, or do we need a new mechanism like UUIDs.  I think
that is something we need to work out, no matter which protocol
mechanism we end up using.

 Fantastic write up.  

> globally known fixed list of strings
Are you suggesting that we would have a client/server negotiation such as, 'jdbc<version>', 'all', etc where that would identify which types are done which way?  If you did that, why would we need to promote names/uuid to permanent global space?

merlin





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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: --sync-method isn't documented to take an argument
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Pre-proposal: unicode normalized text