| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
| Cc: | ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Uncopied parameters on CREATE TABLE LIKE |
| Date: | 2008-07-24 15:41:41 |
| Message-ID: | 584.1216914101@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> On Thu, 2008-07-24 at 10:30 -0400, Tom Lane wrote:
>> Given the very short list of supported
>> reloptions right now, why would you imagine that there will ever
>> be such a thing as installation-local reloptions?
> There's a ton of ways to introduce installation-local code, and we
> support custom_variable_classes to support that. We just need some
> additional flexibility at object level also.
Anyone who's capable of introducing a new reloption is also capable of
modifying reloptions.c to accept it. There is a very specific technical
reason for the existence of custom_variable_classes, which is that the
postmaster will flat out refuse to boot if you have a "bogus" variable
in postgresql.conf, and the code that might want to accept such a
variable might not have been loaded yet. That problem doesn't apply to
reloptions. It's already the case that we ignore "bogus" values in an
already-stored reloption, and I see no reason to accept a value during
CREATE or ALTER TABLE that we don't currently believe is OK.
Now, if you're suggesting we need a plugin hook somewhere in or around
default_reloptions, that's possibly reasonable; but a GUC like you're
suggesting seems quite pointless.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Teodor Sigaev | 2008-07-24 15:53:56 | Re: [PATCHES] GIN improvements |
| Previous Message | Hannu Krosing | 2008-07-24 15:38:49 | Re: Do we really want to migrate plproxy and citext into PG core distribution? |