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

On Tue, 8 Oct 2019 at 11:57, Craig Ringer <craig@2ndquadrant.com> wrote:

On Thu, 11 Jul 2019 at 04:34, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Jul 10, 2019 at 9:59 AM Dave Cramer <pg@fastcrypt.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.

This in fact is the number one reason I want to do this. NPGSQL also benefits from this as well.