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.
Maybe there's a better way, that just seemed like the obvious design.
--
Robert Haas
EDB: http://www.enterprisedb.com