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

Re: generic reloptions improvement

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Simon Riggs <simon(at)2ndQuadrant(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:20:43
Message-ID: 20090103152043.GB4858@alvh.no-ip.org (view raw or flat)
Thread:
Lists: pgsql-hackers
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.

> What you have here looks fairly hard to program for normal users. I
> don't want to reject the feature, but the proposal you have here isn't
> the best it could be...

Agreed ...

> 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.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

In response to

Responses

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2009-01-03 15:24:34
Subject: Re: reloptions and toast tables
Previous:From: Alvaro HerreraDate: 2009-01-03 15:17:32
Subject: Re: generic reloptions improvement

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