MIME-Version: 1.0
References: <e44327179e5c9015c8dda67351c04da552066017.camel@j-davis.com>
 <b701501541a424111ffe47be055e0ccefefd7745.camel@j-davis.com>
 <2cf41c8edeaaf7acb757095e6eceab8ae926f3da.camel@j-davis.com> <CABwTF4XWKqx06UxApH8pnBdp_w2iL6VEbGKxDyjCW7-FNhLCBQ@mail.gmail.com>
In-Reply-To: <CABwTF4XWKqx06UxApH8pnBdp_w2iL6VEbGKxDyjCW7-FNhLCBQ@mail.gmail.com>
From: "David G. Johnston" <david.g.johnston@gmail.com>
Date: Thu, 13 Jul 2023 13:37:24 -0700
Message-ID: <CAKFQuwbcUv9QmrfQKRRi1aq4E68xHD9N05_VZ2TLbMpxMV9Opg@mail.gmail.com>
Subject: Re: Fix search_path for all maintenance commands
To: Gurjeet Singh <gurjeet@singh.im>
Cc: Jeff Davis <pgsql@j-davis.com>, 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>
Content-Type: multipart/alternative; boundary="000000000000c6326c0600644da7"
Archived-At: <https://www.postgresql.org/message-id/CAKFQuwbcUv9QmrfQKRRi1aq4E68xHD9N05_VZ2TLbMpxMV9Opg%40mail.gmail.com>
Precedence: bulk

--000000000000c6326c0600644da7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jul 13, 2023 at 12:54=E2=80=AFPM Gurjeet Singh <gurjeet@singh.im> w=
rote:

>
> The approach seems good to me. My concern is with this change's
> potential to cause an extended database outage. Hence sending it out
> as part of v16, without any escape hatch for the DBA, is my objection.
>
>
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.

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. And I'm against simply breaking the past without any recourse as what
we did for pg_dump/pg_restore still bothers me.

David J.

--000000000000c6326c0600644da7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon=
t-family:arial,helvetica,sans-serif"><span style=3D"font-family:Arial,Helve=
tica,sans-serif">On Thu, Jul 13, 2023 at 12:54=E2=80=AFPM Gurjeet Singh &lt=
;<a href=3D"mailto:gurjeet@singh.im">gurjeet@singh.im</a>&gt; wrote:</span>=
<br></div></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);=
padding-left:1ex"><br>
The approach seems good to me. My concern is with this change&#39;s<br>
potential to cause an extended database outage. Hence sending it out<br>
as part of v16, without any escape hatch for the DBA, is my objection.<br><=
br></blockquote><div><br></div><div class=3D"gmail_default" style=3D"font-f=
amily:arial,helvetica,sans-serif">If this is limited to MAINT, which I&#39;=
m in support of, there is no need for an &quot;escape hatch&quot;.=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.</div><div class=3D"gmail_default" =
style=3D"font-family:arial,helvetica,sans-serif"><br></div><div class=3D"gm=
ail_default" style=3D"font-family:arial,helvetica,sans-serif">Tom&#39;s opi=
nion was a general dislike for differing behavior in different situations.=
=C2=A0 I dislike it too, on purist grounds, but would rather do this than n=
ot make any forward progress because we made a poor decision in the past. A=
nd I&#39;m against simply breaking the past without any recourse as what we=
 did for pg_dump/pg_restore still bothers me.</div><div class=3D"gmail_defa=
ult" style=3D"font-family:arial,helvetica,sans-serif"><br></div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif">David J=
.</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sa=
ns-serif"><br></div></div></div>

--000000000000c6326c0600644da7--