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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
