Re: vacuum_truncate configuration parameter and isset_offset

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: vacuum_truncate configuration parameter and isset_offset
Дата
Msg-id CAKFQuwY+175tfbq27RkcDbSUb+bFVvDZW18-R6V0oFQ4dHAAUA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: vacuum_truncate configuration parameter and isset_offset  (Nathan Bossart <nathandbossart@gmail.com>)
Список pgsql-hackers
On Wed, Mar 26, 2025 at 9:14 AM Nathan Bossart <nathandbossart@gmail.com> wrote:
FWIW one of the big reasons I didn't proceed with the enum approach
initially is because I worried that I'd end up in a similar discussion
about how terrible _that_ approach is.  When I look at that patch [0], I
genuinely wonder if folks would accept that without the isset_offset
context.  Maybe I misjudged...


I think this discussion was going to happen no matter which approach was actually committed.  The concept of "is set" is too obvious and clean a solution to not be brought up and considered; while at the same time this argument about staying consistent with nearby code, even in the face of a hack-ish implementation, was going to need to be explicitly considered.

This discussion was preordained the moment we decided to add vacuum_truncate to the system.  It was only a matter of when.  And while hindsight is 20-20 your own comments regarding your uncertainty suggests you at least had an inkling of suspicion that this discussion was going to be part of the outcome of committing this.

I would have been fine with: "I committed this approach because it's cleaner, and here is why I dislike the enum approach.  Let's have a discussion in May if this choice is unappealing for reasons."  Getting in the user-facing feature "DBA choice of default" before feature freeze was warranted and the patch as committed did meet all the necessary requirements.

David J.

В списке pgsql-hackers по дате отправления: