Skip site navigation (1) Skip section navigation (2)

Re: generic reloptions improvement

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 (view raw or flat)
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


In response to

Responses

pgsql-hackers by date

Next:From: KaiGai KoheiDate: 2009-01-03 15:59:37
Subject: Re: generic reloptions improvement
Previous:From: Tom LaneDate: 2009-01-03 15:26:18
Subject: Re: [BUGS] BUG #4599: bugfix for contrib/dblink module

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group