From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
Cc: | Dave Cramer <davecramer(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jeff Davis <pgsql(at)j-davis(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Request for comment on setting binary format output per session |
Date: | 2023-10-04 16:26:31 |
Message-ID: | CAHyXU0wkg2Gt03q_Xu=BSd3u7hh7X9BL1cd_menH=9Xxb2fkew@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Oct 4, 2023 at 9:17 AM Peter Eisentraut <peter(at)eisentraut(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2023-10-04 17:16:22 | Re: Pre-proposal: unicode normalized text |
Previous Message | Tom Lane | 2023-10-04 16:24:36 | Re: --sync-method isn't documented to take an argument |