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

Поиск
Список
Период
Сортировка
От Dave Cramer
Тема Re: Request for comment on setting binary format output per session
Дата
Msg-id CADK3HHK9XqxtVeuZvSvGtLaZK4eYFmshz5XF=cUrDmLdeZOCKw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Request for comment on setting binary format output per session  (Jeff Davis <pgsql@j-davis.com>)
Ответы Re: Request for comment on setting binary format output per session  (Jeff Davis <pgsql@j-davis.com>)
Список pgsql-hackers


On Tue, 28 Mar 2023 at 19:01, Jeff Davis <pgsql@j-davis.com> wrote:
On Tue, 2023-03-28 at 10:22 -0400, Dave Cramer wrote:
> OK, IIUC what you are proposing here is that there would be a
> separate pool for 
> database, user, and OIDs. This doesn't seem too flexible. For
> instance if I create a UDT and then want it to be returned 
> as binary then I have to reconfigure the pool to be able to accept a
> new list of OID's.

There are two ways that I could imagine the connection pool working:

1. Accept whatever clients connect, and pass along the binary_formats
setting to the outbound (server) connection. The downside here is that
if you have many different clients (or different versions) that have
different binary_formats settings, then it creates too many pools and
doesn't share well enough.
As I understand it, pools create connections before the client actually requests the connection.
This would necessitate having the binary format information in the configuration file.

I'm starting to wonder about the utility of the protocol extension mechanism? 
It would seem that you would need to add the new feature into all pools ? 

2. Some kind of configuration setting (or maybe it can be done
automatically) that organizes based on a common subset of binary
formats that many clients can understand.
 
Well that would bring us back to just providing a list of OID's of well known types as I first proposed instead of trying to accomodate UDT's 

Dave
 

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: BufmgrCommit no-op since 2008, remaining uses?
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: Tab completion for AT TIME ZONE