On Wed, 9 Oct 2019 at 08:15, Dave Cramer <p...@fastcrypt.com> wrote: > > > On Tue, 8 Oct 2019 at 11:57, Craig Ringer <cr...@2ndquadrant.com> wrote: > >> On Thu, 11 Jul 2019 at 04:34, Tom Lane <t...@sss.pgh.pa.us> wrote: >> >>> Robert Haas <robertmh...@gmail.com> writes: >>> > On Wed, Jul 10, 2019 at 9:59 AM Dave Cramer <p...@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. > > 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 da...@postgresintl.com www.postgresintl.com
0001-Add-a-STARTUP-packet-option-to-set-GUC_REPORT-on-GUC.patch
Description: Binary data
