Re: generic reloptions improvement

Alvaro Herrera wrote:
> Tom Lane wrote:
> > Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
>
> > > I'm intending to have a new routine which would reserve a value at
> > > runtime. This value would be later be passed by the AM to create new
> > > options on the table.
> >
> > What do you mean by "at runtime"? Surely the value would have to remain
> > stable across database restarts, since it's going to relate to stuff
> > that is in catalog entries.
>
> No, there's no need for the value to be stable across restart; what's
> stored in catalogs is the option name, which is linked to the kind
> number only in the parser table.

So this is an updated patch. This now allows a user-defined AM to
create new reloptions and pass them down to the parser for parsing and
checking. I also attach a proof-of-concept patch that adds three new
options to btree (which do nothing apart from logging a message at
insert time). This patch demonstrates the coding pattern that a
user-defined AM should follow to add and use new storage options.

The main thing I find slightly hateful about this patch is that the code
to translate from the returned relopt_value array and the fixed struct
is rather verbose; and that the AM needs to duplicate the code in
default_reloptions. I don't find it ugly enough to warrant objecting to
the patch as a whole however.

The neat thing about this code is that the parsing and searching is done
only once, when the relcache entry is loaded. Later accesses to the
option values themselves is just a struct access, and thus plenty quick.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.