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

On Thu, 11 Jul 2019 at 04: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.
>

Yep. For search_path I definitely agree.

In other places I've (ab)used GUC_REPORT to push information back to the
client as a workaround for the lack of protocol extensibility / custom
messages. It's a little less ugly than abusing NOTICE messages. I'd prefer
a real way to add optional/extension messages, but in the absence of that
extension-defined GUCs may have good reasons to want to report multiple
changes within a single statement/function/etc.

With that said, most of the time I think we could argue that it's
reasonable to fire a GUC_REPORT if the *top-level* GUC nestlevel values
change. That'd solve the search_path spam issue while still giving Dave
what he wants, amongst other things.

BTW, a good argument for the client wanting to be notified of search_path
changes might be for clients that want to cache name=>oid mappings for
types, relations, etc. The JDBC driver would be able to benefit from that
if it could trust that the same name would map to the same type (for a
top-level statement) in future, but currently it can't.

--
Craig Ringer http://www.2ndQuadrant.com/
2ndQuadrant - PostgreSQL Solutions for the Enterprise