Re: [PATCH] Replace magic constant 3 with NUM_MERGE_MATCH_KINDS

Поиск
Список
Период
Сортировка
От Dean Rasheed
Тема Re: [PATCH] Replace magic constant 3 with NUM_MERGE_MATCH_KINDS
Дата
Msg-id CAEZATCUi_t69sEcdAqAWOV6618f0pVYg2TfAPi=rQh-AuOZpgA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PATCH] Replace magic constant 3 with NUM_MERGE_MATCH_KINDS  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers
On Mon, 22 Apr 2024 at 06:04, Michael Paquier <michael@paquier.xyz> wrote:
>
> On Fri, Apr 19, 2024 at 12:47:43PM +0300, Aleksander Alekseev wrote:
> > Thanks. I see a few pieces of code that use special FOO_NUMBER enum
> > values instead of a macro. Should we refactor these pieces
> > accordingly? PFA another patch.
>
> I don't see why not for the places you are changing here, we can be
> more consistent.

[Shrug] I do prefer using a macro. Adding a counter element to the end
of the enum feels like a hack, because the counter isn't the same kind
of thing as all the other enum elements, so it feels out of place in
the enum. On the other hand, I think it's a fairly common pattern that
most people will recognise, and for other enums that are more likely
to grow over time, it might be less error-prone than a macro, which
people might overlook and fail to update.

>  Now, such changes are material for v18.

Agreed. This has been added to the next commitfest, so let's see what
others think.

Regards,
Dean



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

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Direct SSL connection with ALPN and HBA rules
Следующее
От: Alexander Lakhin
Дата:
Сообщение: Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan