Re: proposal: psql: show current user in prompt

út 12. 9. 2023 v 9:46 odesílatel Peter Eisentraut <peter(at)eisentraut(dot)org>
napsal:

> On 11.09.23 13:59, Jelte Fennema wrote:
> > @Tom and @Robert, since you originally suggested extending the
> > protocol for this, I think some input from you on the protocol design
> > would be quite helpful. BTW, this protocol extension is the main
> > reason I personally care for this patch, because it would allow
> > PgBouncer to ask for updates on certain GUCs so that it can preserve
> > session level SET commands even in transaction pooling mode.
> > Right now PgBouncer can only do this for a handful of GUCs, but
> > there's quite a few others that are useful for PgBouncer to preserve
> > by default:
> > - search_path
> > - statement_timeout
> > - lock_timeout
>
> 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.
>

Introducing this GUC, mainly when the usage will be limited to connection
string, makes sense to me. Unfortunately for usage in psql it is not
practical.

* For secure usage this GUC should be session immutable - probably you
don't want to disable reporting for search_path, ... inside session
* Enhancing list requires more work - reading current state, parsing
(theoretically the GUC "report these variables" can be marked as
GUC_REPORT, so I can see this value on client side, but still there is
parsing. I can imagine enhancing the SET command to style SET GUC += value
or SET GUC -= value
* SET statement is transactional - that means it cannot be used when a
transaction is broken, but it can be solved by some protocol based command
for setting GUC without dependency on state of transaction (if it is
possible, my functions changes just flag of some existing GUC, so there is
not necessary memory allocation, changing the value can be different story).

I can imagine both access - special GUC allowed only in connection string -
that can work as protection against unwanted remove of GUC_REPORT too, and
dedicated functions for enabling, disabling GUC_REPORT. It can very nicely
work together. Then we don't need any other changes. There is no necessity
for protocol SET, there is no necessity for more user friendly work with
lists in SET statements. And with connect settings for reporting, proxies
can easily detect and get the values of GUC.

Regards

Pavel