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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2009-01-03 15:24:34 | Re: reloptions and toast tables |
Previous Message | Alvaro Herrera | 2009-01-03 15:17:32 | Re: generic reloptions improvement |