On Thu, 2023-07-13 at 13:37 -0700, David G. Johnston wrote: > If this is limited to MAINT, which I'm in support of, there is no > need for an "escape hatch". A prerequisite for leveraging the new > feature is that you fix the code so it conforms to the new way of > doing things.
The current patch is not limited to exercise of the MAINTAIN privilege. > Tom's opinion was a general dislike for differing behavior in > different situations. I dislike it too, on purist grounds, but would > rather do this than not make any forward progress because we made a > poor decision in the past. I believe the opinion you're referring to is here: https://www.postgresql.org/message-id/1659699.1688086...@sss.pgh.pa.us Which was a reaction to another version of my patch which implemented your idea to limit the changes to the MAINTAIN privilege. I agree with you that we should be practical here. The end goal is to move users away from using functions that both (a) implicitly depend on the search_path; and (b) are called implicitly as a side-effect of accessing a table. Whatever is the fastest and smoothest way to get there is fine with me. > And I'm against simply breaking the past without any recourse as what > we did for pg_dump/pg_restore still bothers me. Is a GUC the solution here? Gurjeet called it heavy-handed, and I see the point that carrying such a GUC forever would be unpleasant. But if it reduces the risk of breakage (or at least offers an escape hatch) then it may be wise, and hopefully we can remove it later. Regards, Jeff Davis
