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

On Wed, 9 Oct 2019 at 08:15, Dave Cramer <pg(at)fastcrypt(dot)com> wrote:

>
>
> 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.
>
>
I've added functionality into libpq to be able to set this STARTUP
parameter as well as changed it to _pq_.report.
Still need to document this and figure out how to test it.

See attached patch

Dave Cramer

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