From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> |
Subject: | Re: generic reloptions improvement |
Date: | 2009-01-03 15:54:58 |
Message-ID: | 1230998098.4032.185.camel@ebony.2ndQuadrant |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | KaiGai Kohei | 2009-01-03 15:59:37 | Re: generic reloptions improvement |
Previous Message | Tom Lane | 2009-01-03 15:26:18 | Re: [BUGS] BUG #4599: bugfix for contrib/dblink module |