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
> > 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.
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
In response to
pgsql-hackers by date
|Next:||From: KaiGai Kohei||Date: 2009-01-03 15:59:37|
|Subject: Re: generic reloptions improvement|
|Previous:||From: Tom Lane||Date: 2009-01-03 15:26:18|
|Subject: Re: [BUGS] BUG #4599: bugfix for contrib/dblink module |