Re: proposal: psql: show current user in prompt
От | Jelte Fennema-Nio |
---|---|
Тема | Re: proposal: psql: show current user in prompt |
Дата | |
Msg-id | CAGECzQSg0ND=gRmpZHBsiaZT5-a17y=VFf3AQfi5N7oECtM1Ug@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: proposal: psql: show current user in prompt (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: proposal: psql: show current user in prompt
(Pavel Stehule <pavel.stehule@gmail.com>)
|
Список | pgsql-hackers |
On Sat, 27 Jan 2024 at 20:44, Pavel Stehule <pavel.stehule@gmail.com> wrote: > 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. libpq could add these ones automatically to the list, just like a proxy. But I think you are probably right and always reporting our current default set is probably easier. >> 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 parsershould 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. Yes, proxies should be smart about it. But if there's new message types introduced specifically for this, then proxies need to be smart about it too. Because they would need to remember which reporting was requested by the client, to be able to correctly ask for reporting GUCs it after server connection . Using GUCs actually makes this easier to implement (and thus less error prone), because proxies already have logic to re-sync GUCs after connection assignment. I think this is probably one of the core reasons why I would very much prefer GUCs over new message types to configure protocol extensions like this: It means proxies would not to keep track of and re-sync a new kind of connection state every time a protocol extension is added. They can make their GUC tracking and re-syncing robust, and that's all they would need. > This is true, but how common is this situation? Probably every client that uses one proxy will use the same defaultlyreported GUC. If you have different clients connecting to the same proxy, it seems quite likely that this will happen. This does not seem uncommon to me, e.g. actual application would need different things always reported than some dev client. Or clients for different languages might ask to report slightly different settings. > Reporting has no extra overhead. The notification is reduced. When there is a different set of reported GUC, then the proxycan try to find another connection with the same set or can reconnect. Honestly, this logic seems much more fragile to implement. And requiring reconnection seems problematic from a performance point of view. > 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, thenmy case, prompt in psql will be broken too. Inside psql I have not callback on change of reported GUC. So this is reasonwhy reporting based on mutable GUC is fragile :-/ Specifically for this reason, the current patchset in the other thread already ignores RESET ALL and DISCARD ALL for protocol extension parameters (including _pq_.report_parameters). So this would be a non-issue.
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Alena RybakinaДата:
Сообщение: Re: Evaluate arguments of correlated SubPlans in the referencing ExprState
Следующее
От: Jelte Fennema-NioДата:
Сообщение: Re: [EXTERNAL] Re: Add non-blocking version of PQcancel