Re: proposal: psql: show current user in prompt
От | Jelte Fennema-Nio |
---|---|
Тема | Re: proposal: psql: show current user in prompt |
Дата | |
Msg-id | CAGECzQT4r-rWKsXVY=v6=T75jkrDxeuxOSKkUa18MKE6ePkXhg@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 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. > 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" shouldbe necessary for pgbouncer, then surely the disabling reporting should be ignored. The user by setting a prompt shouldnot break communication. And it can be ignored without any issue, there is not performance issue, because "role" isstill necessary for pgbouncer that is used for connection. Without described behaviour we should not implement controllingreporting to psql, because there can be a lot of unhappy side effects in dependency if the user set or unset customprompt 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. 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.
В списке pgsql-hackers по дате отправления:
Следующее
От: Michał KłeczekДата:
Сообщение: Segmentation fault on FreeBSD with GSSAPI authentication