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 CAFj8pRBqfXzAriZM1c6xVLn1kTcXR3VivoNXsXTWN5VO7d-AYA@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 10:24 odesílatel Jelte Fennema-Nio <postgres@jeltef.nl> napsal:
On Sat, 27 Jan 2024 at 08:35, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> Until now, it is not possible to disable reporting. So clients can expect so reporting is workable.

Sure, so if we leave the default as is that's fine. It's not as if
this GUC would be changed without the client knowing, the client would
be the one changing the GUC and thus disabling the sending of
reporting for the default GUCs. If it doesn't want to disable the
reporting, than it simply should not send such a request.

> Do you have a use case, when disabling some of the defaultly reported GUC makes sense?

Mostly if the client doesn't actually use them, e.g. I expect many
clients don't care what the current application_name is. But I do
agree this is not a very strong usecase, so I'd be okay with always
sending the ones that we sent as default for now. But that does make
the implementation more difficult, since we'd have to special case
these GUCs instead of having the same consistent behaviour for all
GUCs.

client_encoding, standard_conforming_strings, server_version, default_transaction_read_only, in_hot_standby and scram_iterations
are used by libpq directly, so it can be wrong to introduce the possibility to break it.



> 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.

Maybe I'm misunderstanding what you're saying, but it's not clear to
me why you are seeing two different use cases here. To me if we have
the ParameterSet message then they are both the same. When you enable
%N you would send a ParamaterSet message for _pq_.report_parameters
and set it to a list of gucs including "role". And when you disable %N
you would set _pq_.report_parameters to a list of GUCs without "role".
Then if any proxy still needed "role" even if the list it receives in
_pq_.report_parameters doesn't contain it, then this proxy would
simply prepend "role" to the list of GUCs before forwarding the
ParameterSet message.

Your scenario can work but looks too fragile. I checked - GUC now cannot contain some special chars, so writing parser should not be hard work. But your proposal means the proxy should be smart about it, and have to check any change of _pq_.report_parameters, and this point can be fragile and a source of hardly searched bugs.
 

Also to be clear, having a "protected" connection-start only GUC is
problematic for proxies. Because they need to update this setting
while the connection is active when they hand of one server connection
to another client.

This is true, but how common is this situation? Probably every client  that uses one proxy will use the same defaultly reported GUC.  Reporting has no extra overhead. The notification is reduced. When there is a different set of reported GUC, then the proxy can try to find another connection with the same set or can reconnect.  I think so there is still opened question what should be correct behaviour when client execute RESET ALL or DISCARD ALL.  Without special protection the communication with proxy can be broken - and we use GUC for reported variables, then my case, prompt in psql will be broken too. Inside psql I have not callback on change of reported GUC. So this is reason why reporting based on mutable GUC is fragile :-/

Pavel

pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: logical decoding and replication of sequences, take 2
Next
From: vignesh C
Date:
Subject: Re: [EXTERNAL] Re: Add non-blocking version of PQcancel