Re: Fix search_path for all maintenance commands - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: Fix search_path for all maintenance commands
Date
Msg-id CAKFQuwbcUv9QmrfQKRRi1aq4E68xHD9N05_VZ2TLbMpxMV9Opg@mail.gmail.com
Whole thread Raw
In response to Re: Fix search_path for all maintenance commands  (Gurjeet Singh <gurjeet@singh.im>)
Responses Re: Fix search_path for all maintenance commands
Re: Fix search_path for all maintenance commands
List pgsql-hackers
On Thu, Jul 13, 2023 at 12:54 PM Gurjeet Singh <gurjeet@singh.im> wrote:

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.

pgsql-hackers by date:

Previous
From: Melih Mutlu
Date:
Subject: Re: [PATCH] Reuse Workers and Replication Slots during Logical Replication
Next
From: Andres Freund
Date:
Subject: Re: vac_truncate_clog()'s bogus check leads to bogusness