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: | Raw Message | Whole Thread | 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? |