On Wed, Apr 5, 2023 at 9:56 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: > > On Tue, Apr 4, 2023 at 12:42 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> Basically, I want to reject this on the grounds that it's not > >> useful enough to justify the overhead of marking the "role" GUC > >> as GUC_REPORT. > > > I agree with that. I think we need some method for optionally > > reporting values, so that stuff like this can be handled without > > adding it to the wire protocol for everyone. > > It could probably be possible to provide some mechanism for setting > GUC_REPORT on specific variables locally within sessions. I don't > think this'd be much of a protocol-break problem, because clients > should already be coded to deal gracefully with ParameterStatus messages > for variables they don't know. However, connecting that up to something > like a psql prompt feature would still be annoying. I doubt I'd want > to go as far as having psql try to turn on GUC_REPORT automatically > if it sees %N in the prompt ...
Oh, I had it in mind that it would do exactly that. And I think that should be mediated by a wire protocol message, not a GUC, so that users don't mess things up for psql or other clients -- in either direction -- via SET commands.
If the GUC_REPORT should not be used, then only one possibility is enhancing the protocol, about the possibility to read some predefined server's features from the client.
It can be much cheaper than SQL query, and it can be used when the current transaction is aborted. I can imagine a possibility to read server time or a server session role from a prompt processing routine.
But for this specific case, you need to cache the role name somewhere. You can simply get oid everytime, but for role name you need to access to system catalogue, and it is not possible in aborted transactions. So at the end, you probably should read "role" GUC.