Re: generic reloptions improvement

On Tue, 2008-12-30 at 12:31 -0300, Alvaro Herrera wrote:
> 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.

I very much like the idea of adding new/custom options to tables. There
are many uses for that.

What you have here looks fairly hard to program for normal users. I
don't want to reject the feature, but the proposal you have here isn't
the best it could be...

Can we have something like customer variable classes, but just for
reloptions?

e.g. WITH (mymodule.my_option_name = X)
e.g. WITH (funky_trigger.coolness = 25)

We can then create new custom reloptions in roughly the same way we can
create custom variable classes, or ignore them if module not loaded.

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support