Re: proposal: psql: show current user in prompt - Mailing list pgsql-hackers
| From | Pavel Stehule |
|---|---|
| Subject | Re: proposal: psql: show current user in prompt |
| Date | |
| Msg-id | CAFj8pRC=ppsbtRWFUdQ-9_FUoDnO6rce-DyjDfLsvTP853VbBw@mail.gmail.com Whole thread Raw |
| In response to | Re: proposal: psql: show current user in prompt (Jelte Fennema-Nio <postgres@jeltef.nl>) |
| Responses |
Re: proposal: psql: show current user in prompt
|
| List | pgsql-hackers |
so 27. 1. 2024 v 0:04 odesílatel Jelte Fennema-Nio <postgres@jeltef.nl> napsal:
On Fri, 26 Jan 2024 at 21:35, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> I see a possibility of disabling reporting as possibly dangerous. Without reporting encoding you can break psql. So it should be limited just to few values where is known behave.
I agree that client_encoding is a GUC that likely all clients would
want to request reporting for, so I can see the argument for always
sending it. But I wouldn't call it dangerous for a client to be able
to disable reporting for it. Ultimately the client is the one that
decides. A client might just as well completely ignore the reported
value.
Until now, it is not possible to disable reporting. So clients can expect so reporting is workable.
Do you have a use case, when disabling some of the defaultly reported GUC makes sense?
My patch doesn't protect these GUC, and now I think it is a mistake.
>> While I agree it's a little bit less friendly, I think you're
>> overestimating the difficulty of using my proposed approach. Most
>> importantly there's no need to parse the current GUC value. A client
>> always knows what variables it wants to have reported. So anytime that
>> changes the client can simply regenerate the full list of gucs that it
>> wants to report and send that. So something similar to the following
>> pseudo code (using += for string concatenation):
>
>
> I disagree with this - I can imagine some proxies add some own reported GUC and the client can know nothing about it.
I've definitely thought about this case, since it's the main case I
care about as maintainer of PgBouncer. And a client wouldn't need to
know about the extra GUCs that the proxy requires for the proxy to
work correctly. A proxy can quite simply handle this itself in the
following manner: Whenever a client sends a ParameterSet for
_pq_.report_parameters, the proxy could forward to the server after
prepending its own extra GUCs at the front. The proxy wouldn't even
need to parse the list from the client to be able to do that. An even
better behaving proxy, should parse the list of GUCs though and would
only forward the ParameterStatus messages that it receives from the
server if the client requested ParameterStatus updates for them.
yes, inside gradual connect you can enhance the list of custom reported GUC easily.
but for use cases like prompt in psql, I need to enable, disable reporting - but this use case should be independent of "protected" connection related GUC reporting.
For example - when I disable %N, I can disable reporting "role" and disable showing role in prompt. But when "role" should be necessary for pgbouncer, then surely the disabling reporting should be ignored. The user by setting a prompt should not break communication. And it can be ignored without any issue, there is not performance issue, because "role" is still necessary for pgbouncer that is used for connection. Without described behaviour we should not implement controlling reporting to psql, because there can be a lot of unhappy side effects in dependency if the user set or unset custom prompt or some other future feature.
pgsql-hackers by date: