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

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