Re: Psql meta-command conninfo+ - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Psql meta-command conninfo+
Date
Msg-id 3661902.1740170006@sss.pgh.pa.us
Whole thread Raw
In response to Re: Psql meta-command conninfo+  (Sami Imseih <samimseih@gmail.com>)
Responses Re: Psql meta-command conninfo+
List pgsql-hackers
Sami Imseih <samimseih@gmail.com> writes:
>> Maybe keeping track of 'role' via ParameterStatus messages is a good
>> idea for reasons unrelated to this patch -- maybe it can be useful for
>> applications to be aware of role changes -- but I'm not 100% sure about
>> that, and in particular I'm not sure how heavy the protocol traffic is
>> going to be if such messages are emitted every time you run a security
>> invoker function or things like that

> With the latest version of the patch, 'role' is not needed as
> 'session authorization' is not shown either [1].

FWIW, the server currently sends at most one ParameterStatus change
report per query.  So I don't think that there is a huge performance
argument against making 'role' be GUC_REPORT.  On the other hand,
supporting \conninfo is a pretty lousy argument for doing so ---
surely we don't need a constantly-updated value to support a
seldom-used command.  Moreover, if \conninfo depended on that
it wouldn't work with older servers.

If we want to include 'role' in this output, what I'd propose is to
have \conninfo issue "SHOW role", which is accepted by every server
version.  If it fails (say because we're in an aborted transaction),
just omit that row from the output.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Statistics Import and Export
Next
From: Tom Lane
Date:
Subject: Re: Statistics Import and Export