Re: Uncopied parameters on CREATE TABLE LIKE - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Uncopied parameters on CREATE TABLE LIKE
Date
Msg-id 584.1216914101@sss.pgh.pa.us
Whole thread Raw
In response to Re: Uncopied parameters on CREATE TABLE LIKE  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: Uncopied parameters on CREATE TABLE LIKE  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-hackers
Simon Riggs <simon@2ndquadrant.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


pgsql-hackers by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: Do we really want to migrate plproxy and citext into PG core distribution?
Next
From: Teodor Sigaev
Date:
Subject: Re: [PATCHES] GIN improvements