| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | Gurjeet Singh <gurjeet(at)singh(dot)im> |
| Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-hackers(at)postgresql(dot)org, Nathan Bossart <nathandbossart(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, Greg Stark <stark(at)mit(dot)edu>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Subject: | Re: Fix search_path for all maintenance commands |
| Date: | 2023-07-13 20:37:24 |
| Message-ID: | CAKFQuwbcUv9QmrfQKRRi1aq4E68xHD9N05_VZ2TLbMpxMV9Opg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Jul 13, 2023 at 12:54 PM Gurjeet Singh <gurjeet(at)singh(dot)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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2023-07-13 20:45:41 | Re: vac_truncate_clog()'s bogus check leads to bogusness |
| Previous Message | Melih Mutlu | 2023-07-13 20:27:41 | Re: [PATCH] Reuse Workers and Replication Slots during Logical Replication |