Re: Array initialisation notation in syscache.c - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Array initialisation notation in syscache.c
Date
Msg-id CA+hUKGKoPH31RBTAqq9MaTSocc2C28b9yFd9CJeYNrekc+oKgw@mail.gmail.com
Whole thread Raw
In response to Re: Array initialisation notation in syscache.c  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Array initialisation notation in syscache.c  (Thomas Munro <thomas.munro@gmail.com>)
List pgsql-hackers
On Wed, Dec 21, 2022 at 12:05 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Thomas Munro <thomas.munro@gmail.com> writes:
> > Do you think this is better?
>
> I'm not at all on board with adding runtime overhead to
> save maintaining the nkeys fields.

I don't see how to do it at compile time without getting the
preprocessor involved.  What do you think about this version?

    [ATTNUM] = {
        AttributeRelationId,
        AttributeRelidNumIndexId,
        KEY(Anum_pg_attribute_attrelid,
            Anum_pg_attribute_attnum),
        128
    },

> I'm kind of neutral on using "[N] = " as a substitute for
> ordering the entries correctly.  While that does remove
> one failure mode, it seems like it adds another (ie
> failure to provide an entry at all would be masked).

It fails very early in testing if you do that.  Admittedly, the
assertion is hard to understand, but if I add a new assertion close to
the cause with a new comment to say what you did wrong, I think that
should be good enough?

Attachment

pgsql-hackers by date:

Previous
From: Ranier Vilela
Date:
Subject: Avoid lost result of recursion (src/backend/optimizer/util/inherit.c)
Next
From: Justin Pryzby
Date:
Subject: Re: Small miscellaneus fixes (Part II)