On Tue, Apr 28, 2026 at 7:53 PM Dilip Kumar <[email protected]> wrote: > > 2. > > +typedef enum ConflictLogDest > > +{ > > + /* Log conflicts to the server logs */ > > + CONFLICT_LOG_DEST_LOG = 1 << 0, /* 0x01 */ > > + > > + /* Log conflicts to an internally managed conflict log table */ > > + CONFLICT_LOG_DEST_TABLE = 1 << 1, /* 0x02 */ > > + > > + /* Convenience bitmask for all supported destinations */ > > + CONFLICT_LOG_DEST_ALL = (CONFLICT_LOG_DEST_LOG | > > CONFLICT_LOG_DEST_TABLE) > > +} ConflictLogDest; > > + > > +/* > > + * Array mapping for converting internal enum to string. > > + */ > > +static const char *const ConflictLogDestNames[] = { > > + [CONFLICT_LOG_DEST_LOG] = "log", > > + [CONFLICT_LOG_DEST_TABLE] = "table", > > + [CONFLICT_LOG_DEST_ALL] = "all" > > +}; > > > > Defining an array this way could be an Array size issue. Actually the > > array has just three elements so the last element should be at > > ConflictLogDestNames[2] but if we go by the above definition, it will > > be ConflictLogDestNames[3]. Can we define by referring the following > > existing way:
I was analyzing this because I remember we were initially using the format you suggested and switched to the bit format to enable direct bitwise operations elsewhere. I think Peter suggested that [1], and the argument was that the bitwise operation is easy if we represent them as a bit. Also, since we would not have too many options, the array size shouldn't be an issue. But I understand your point: adding more elements will cause the array size to grow very fast as this is using sparse array. Let's see what others think about this, and then we can decide whether to change it back? [1] https://www.postgresql.org/message-id/CAHut%2BPtavTffweLWWQEK7JuDtwLPKhdqLysYg1ipjcoiW80%2B4g%40mail.gmail.com -- Regards, Dilip Kumar Google
