On Wed, Apr 5, 2023 at 9:56 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: > > On Tue, Apr 4, 2023 at 12:42 PM Tom Lane <t...@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
