From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Fabrízio Mello <fabriziomello(at)gmail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] Store Extension Options |
Date: | 2014-01-06 19:16:25 |
Message-ID: | CA+TgmobmQ5ATHr6X_vQVBw5_-f+XV0avTFaGRaRNuyhmEJc2Kw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Jan 5, 2014 at 10:50 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> =?ISO-8859-1?Q?Fabr=EDzio_de_Royes_Mello?= <fabriziomello(at)gmail(dot)com> writes:
>> You are correct. pg_dump export reloptions using "WITH" clause of CREATE
>> TABLE statement. I.e.:
>
>> CREATE TABLE foo (
>> )
>> WITH (autovacuum_enabled=false, bdr.do_replicate=false);
>
>> So if this statement checks for 'bdr' extension is loaded then in partial
>> restore it can be fail.
>
> I see absolutely *nothing* wrong with failing that command if bdr is not
> installed. For an analogy, if this table includes a column of type bar
> defined by some extension baz, we are certainly going to fail the
> CREATE TABLE if baz isn't installed.
>
> Now, if bdr is installed but the validation doesn't happen unless bdr
> is "loaded" in some sense, then that is an implementation deficiency
> that I think we can insist be rectified before this feature is accepted.
We could add a catalog pg_custom_reloption with a reloption namespace,
a reloption name, and a pg_proc OID for a checker-function. This is a
lot more overhead than just having a hook the way we do for GUCs, and
I'm not sure how you'd handle invalidation, but in theory it solves
the problem.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2014-01-06 19:22:10 | Re: ALTER SYSTEM SET command to change postgresql.conf parameters |
Previous Message | Robert Haas | 2014-01-06 19:13:21 | Re: truncating pg_multixact/members |