Re: Updates of SE-PostgreSQL 8.4devel patches (r1389)

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Tom Lane wrote:
>> What you seem to be supposing is that the only possible use pattern
>> for these macros is a for-loop containing nothing but calls to one
>> or another of the macros.

> You're right. I initially wrote these macros to reduce the amount of
> code in heap_reloptions, but apparently went too far with what to
> include in them. Perhaps it's better to define them this way:
> ...
> With these
> definitions, default_reloptions looks like this (of course, the
> "continue" makes no sense in this case, but it would if there were more
> options):

> for (i = 0; i < numoptions; i++)
> {
> if (HAVE_RELOPTION("fillfactor", options[i]))
> {
> HANDLE_INT_RELOPTION("fillfactor", rdopts->fillfactor, options[i],
> (char *) NULL);
> continue;
> }
> }

I guess I'm still wondering which part of this actually needs to be
hand-coded so that it can be flexible. I'm envisioning the whole
loop replaced by something like

FillRelOptions((void *) rdopts, options, &constanttable);

where the constant table contains entries like

{ "fillfactor", RELOPT_TYPE_INT, offsetof(StdRdOptions, fillfactor) }

BTW, are we just assuming that there's never a possibility of no match?
It seems like there ought to be an elog complaint if you get to the
bottom of the loop; which again is something I don't see the point of
writing out each time.

regards, tom lane