Re: let's make the list of reportable GUCs configurable (was Re: Add %r substitution for psql prompts to show recovery status)

On Wed, 10 Jul 2019 at 16:34, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > On Wed, Jul 10, 2019 at 9:59 AM Dave Cramer <pg(at)fastcrypt(dot)com> wrote:
> >> I'm still a bit conflicted about what to do with search_path as I do
> believe this is potentially a security issue.
> >> It may be that we always want to report that and possibly back patch it.
>
> > I don't see that as a feasible option unless we make the logic that
> > does the reporting smarter. If it changes transiently inside of a
> > security-definer function, and then changes back, my recollection is
> > that right now we would report both changes. I think that could cause
> > a serious efficiency problem if you are calling such a function in a
> > loop.
>
> And, even more to the point, what's the client side going to do with
> the information? If there was a security problem inside the
> security-definer function, it's too late. And the client can't do
> much about it anyway.
>
> If we have a configurable GUC_REPORT list, and somebody thinks it's useful
> to them to report search_path, I don't wish to stand in their way.
> But the argument that this is useful is so tissue-thin that we have no
> business imposing the overhead on everybody, much less back-patching it.
>
> regards, tom lane
>

See attached for an initial patch. If this is an acceptable way to go I
will add tests and documentation