Alvaro Herrera <alvhe...@commandprompt.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
