Re: [PATCH] Replace magic constant 3 with NUM_MERGE_MATCH_KINDS

From: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Aleksander Alekseev <aleksander(at)timescale(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Richard Guo <guofenglinux(at)gmail(dot)com>
Subject: Re: [PATCH] Replace magic constant 3 with NUM_MERGE_MATCH_KINDS
Date: 2024-04-22 07:55:37
Message-ID: CAEZATCUi_t69sEcdAqAWOV6618f0pVYg2TfAPi=rQh-AuOZpgA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 22 Apr 2024 at 06:04, Michael Paquier <michael(at)paquier(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Lakhin 2024-04-22 08:00:00 Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan
Previous Message Heikki Linnakangas 2024-04-22 07:47:51 Re: Direct SSL connection with ALPN and HBA rules