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
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 |