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

On Tue, 8 Oct 2019 at 11:57, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:

> 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.
>

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

Dave Cramer

davec(at)postgresintl(dot)com
www.postgresintl.com

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