On Tue, 16 Apr 2024 at 11:35, Richard Guo <guofengli...@gmail.com> wrote: > > On Tue, Apr 16, 2024 at 5:48 PM Aleksander Alekseev > <aleksan...@timescale.com> wrote: >> >> Oversight of 0294df2f1f84 [1]. >> >> [1]: >> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=0294df2f1f84 > > +1. I think this change improves the code quality. I searched for > other arrays indexed by merge match kind, but found none. So this patch > seems thorough. >
Yes this makes sense, though I note that some other similar code uses a #define rather than inserting an enum element at the end (e.g., NUM_ROWFILTER_PUBACTIONS). I guess the argument against inserting an enum element at the end is that a switch statement on the enum value might generate a compiler warning if it didn't have a default clause. Looking at how NUM_ROWFILTER_PUBACTIONS is defined as the last element plus one, it might seem to be barely any better than just defining it to be 3, since any new enum element would probably be added at the end, requiring it to be updated in any case. But if the number of elements were much larger, it would be much more obviously correct, making it a good general pattern to follow. So in the interests of code consistency, I think we should do the same here. Regards, Dean
