Re: generic reloptions improvement

On Sat, 2009-01-03 at 12:20 -0300, Alvaro Herrera wrote:
> Simon Riggs wrote:
>
> > I very much like the idea of adding new/custom options to tables. There
> > are many uses for that.
>
> Hmm, like what? I'm not sure how would it work for tables; you'd have
> to add the options during _PG_init or something like that, and I haven't
> tried it. It's mainly for user-defined AMs that this was done.

I understand and agree with your intended use. I see others as well and
would like to cater for them all in a generic way that will have many
uses over next 10-20 years, many of which I haven't thought of yet.

Custom variable classes are often useful, but they are system wide. It
would be good to be able to use table-level options and have them work
very similarly to something we already have. Table-level options are
just an obvious "normalisation" of how we handle parameters.

If you really can't see a use for this, OK, then: Please can you put in
a plugin API for user defined reloptions as well as what you are
proposing. We discussed this before in late July/early Aug on thread
"Uncopied parameters..."

> > 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.
>
> I'm now playing with adding "namespaces" to the options, but that's for
> handling options for toast tables. I'm not really sure how would it
> work for regular options.

toast.option_x
btree.option_y
autovacuum.option_z

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