From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> |
Cc: | Peter Eisentraut <peter(at)eisentraut(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kirk Wolak <wolakk(at)gmail(dot)com>, Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: proposal: psql: show current user in prompt |
Date: | 2024-01-25 20:42:47 |
Message-ID: | CAFj8pRAQNojO7ttpzXOugg+5rEvpvhM7b2c9PsQX4mLuFLJ44g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi
čt 11. 1. 2024 v 12:12 odesílatel Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>
napsal:
> On Tue, 12 Sept 2023 at 09:46, Peter Eisentraut <peter(at)eisentraut(dot)org>
> wrote:
> > ISTM that for a purpose like pgbouncer, it would be simpler to add a new
> > GUC "report these variables" and send that in the startup message? That
> > might not help with the psql use case, but it would be much simpler.
>
> FYI I implemented it that way yesterday on this other thread (patch
> 0010 of that patchset):
>
> https://www.postgresql.org/message-id/flat/CAGECzQScQ3N-Ykv2j4NDyDtrPPc3FpRoa%3DLZ-2Uj2ocA4zr%3D4Q%40mail.gmail.com#cd9e8407820d492e8f677ee6a67c21ce
I read your patch, and I see some advantages and some disadvantages.
1. this doesn't need new protocol API just for this feature, what is nice
2. using GUC for all reported GUC looks not too readable. Maybe it should
be used just for customized reporting, not for default
3. Another issue of your proposal is less friendly enabling disabling
reporting of specific GUC. Maintaining a list needs more work than just
enabling and disabling one specific GUC.
I think this is the main disadvantage of your proposal. In my proposal I
don't need to know the state of any GUC. Just I send PQlinkParameterStatus
or PQunlinkParameterStatus. With your proposal, I need to read
_pq_.report_parameters, parse it, and modify, and send it back. This
doesn't look too practical.
Personally I prefer usage of a more generic API than my
PQlinkParameterStatus and PQunlinkParameterStatus. You talked about it with
Robert If I remember.
Can be nice if I can write just
/* similar princip is used inside ncurses */
set_report_guc_message_no = PQgetMessageNo("set_report_guc");
/* the result can be processed by server and by all proxies on the line */
if (set_report_guc_message_no == -1)
fprintf(stderr, "feature is not supported");
result = PQsendMessage(set_report_guc_message, "user");
if (result == -1)
fprintf(stderr, "some error ...");
With some API like this it can be easier to do some small protocol
enhancement. Maybe this is overengineering. Enhancing protocol is not too
common, and with usage PQsendTypedCommand enhancing protocol is less work
too.
Regards
Pavel
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Cramer | 2024-01-25 20:56:20 | Re: [PATCH] Add native windows on arm64 support |
Previous Message | Tom Lane | 2024-01-25 20:33:51 | Re: More new SQL/JSON item methods |