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. Dave Cramer da...@postgresintl.com www.postgresintl.com > > -- > Craig Ringer http://www.2ndQuadrant.com/ > 2ndQuadrant - PostgreSQL Solutions for the Enterprise >
