Re: portability of "designated initializers"

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Tom Lane wrote:
>> Where/why do you need to do that?

> The reloptions patch uses three arrays, one for each type of option
> (bool, int, float). I'm wondering if we could use a single array with
> all options, and a union containing the values. The only problem with
> that (AFAICS) is the initialization.

Hmm ... I'd not looked at that patch before, but now that I have I think
it's gone pretty seriously off on the overdesigned-and-inefficient end
of the spectrum. Turning RelationGetFillFactor and friends from simple
macros into functions that are probably *at least* a thousand times slower
than the macros doesn't seem like a good idea at all. Deconstructing a
reloptions datum is supposed to be done once by the relcache, not every
time one of the values is needed. Frankly I'd throw the entire thing
away and go back to a hardwired set of options feeding into a predefined
struct that's held by the relcache and examined by callers.

But as for your immediate point, I don't see that you'd buy enough
notational savings to justify upping our compiler requirement to C99.
All you really need here is to merge the three arrays into a single
array of pointer to struct relopt_gen. It'd be slightly
different-looking from guc.c but only because the pointer array
would be a constant rather than built on the fly.

static const struct relopt_bool relOptAutovacuumEnabled =
{
"autovacuum_enabled",
"Enables autovacuum in this relation",
RELOPT_TYPE_BOOL,
RELOPT_KIND_HEAP,
false
};

static const struct relopt_int relOptFillFactor =
{
"fillfactor",
"Packs table pages only to this percentage",
RELOPT_TYPE_INT,
RELOPT_KIND_HEAP | RELOPT_KIND_INDEX,
100,
10,
100
};

... more ...

static const struct relopt_gen * const relOpts[] =
{
(const struct relopt_gen *) &relOptAutovacuumEnabled,
(const struct relopt_gen *) &relOptFillFactor,
... more ... ,
NULL
};

regards, tom lane