Message-ID: <b690d5927d0193cc6822223d6120b22f52c64d53.camel@j-davis.com>
Subject: Re: Fix search_path for all maintenance commands
From: Jeff Davis <pgsql@j-davis.com>
To: "David G. Johnston" <david.g.johnston@gmail.com>, Gurjeet Singh
	 <gurjeet@singh.im>
Cc: pgsql-hackers@postgresql.org, Nathan Bossart <nathandbossart@gmail.com>,
  Robert Haas <robertmhaas@gmail.com>, Noah Misch <noah@leadboat.com>, Greg
 Stark <stark@mit.edu>, Tom Lane <tgl@sss.pgh.pa.us>
Date: Thu, 13 Jul 2023 15:19:42 -0700
In-Reply-To: <CAKFQuwbcUv9QmrfQKRRi1aq4E68xHD9N05_VZ2TLbMpxMV9Opg@mail.gmail.com>
References: <e44327179e5c9015c8dda67351c04da552066017.camel@j-davis.com>
	 <b701501541a424111ffe47be055e0ccefefd7745.camel@j-davis.com>
	 <2cf41c8edeaaf7acb757095e6eceab8ae926f3da.camel@j-davis.com>
	 <CABwTF4XWKqx06UxApH8pnBdp_w2iL6VEbGKxDyjCW7-FNhLCBQ@mail.gmail.com>
	 <CAKFQuwbcUv9QmrfQKRRi1aq4E68xHD9N05_VZ2TLbMpxMV9Opg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.44.4-0ubuntu1 
MIME-Version: 1.0
Archived-At: <https://www.postgresql.org/message-id/b690d5927d0193cc6822223d6120b22f52c64d53.camel%40j-davis.com>
Precedence: bulk

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".=C2=A0 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.=C2=A0 I dislike it too, on purist grounds, but woul=
d
> 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.1688086436@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