Tom Lane wrote:
> 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) }
I attach a patch that does things this way (it includes the btree test
code because I'm too lazy right now to strip it out).
I'm not really sure about removing the other macros completely, because
they would be useful whenever one wanted to create something
nonstandard.
> 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.
We need to be quiet about it when not validating, I think.
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.