Re: Fix search_path for all maintenance commands

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: Fix search_path for all maintenance commands
Дата
Msg-id CAKFQuwbcUv9QmrfQKRRi1aq4E68xHD9N05_VZ2TLbMpxMV9Opg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Fix search_path for all maintenance commands  (Gurjeet Singh <gurjeet@singh.im>)
Ответы Re: Fix search_path for all maintenance commands  (Gurjeet Singh <gurjeet@singh.im>)
Re: Fix search_path for all maintenance commands  (Jeff Davis <pgsql@j-davis.com>)
Список 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 по дате отправления:

Предыдущее
От: Melih Mutlu
Дата:
Сообщение: Re: [PATCH] Reuse Workers and Replication Slots during Logical Replication
Следующее
От: Andres Freund
Дата:
Сообщение: Re: vac_truncate_clog()'s bogus check leads to bogusness