| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | Jelte Fennema-Nio <me(at)jeltef(dot)nl>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Cc: | Dave Cramer <davecramer(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Jacob Burroughs <jburroughs(at)instructure(dot)com>, "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org> |
| Subject: | Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs |
| Date: | 2023-12-29 18:32:15 |
| Message-ID: | 71c95ce00114088203436242dc55594d09a3e390.camel@j-davis.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, 2023-12-29 at 18:29 +0100, Jelte Fennema-Nio wrote:
> 2. It paves the way for GUCs that can only be set using a protocol
> message (and not using SET).
That sounds useful for GUCs that can interfere with the client, such as
client_encoding or the proposed GUC in you referred to at [1].
> There's definitely still some more work that needs to be done
> (docs for new libpq APIs, protocol version bump, working protocol
> version negotiation).
That is my biggest concern right now: what will new clients connecting
to old servers do?
If the version is bumped, should we look around for other unrelated
protocol changes to make at the same time? Do we want a more generic
form of negotiation?
Regards,
Jeff Davis
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2023-12-29 18:38:07 | Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs |
| Previous Message | Tom Lane | 2023-12-29 18:23:17 | Re: Avoid computing ORDER BY junk columns unnecessarily |