Re: [PATCH] Store Extension Options
От | Robert Haas |
---|---|
Тема | Re: [PATCH] Store Extension Options |
Дата | |
Msg-id | CA+TgmobmQ5ATHr6X_vQVBw5_-f+XV0avTFaGRaRNuyhmEJc2Kw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PATCH] Store Extension Options (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [PATCH] Store Extension Options
|
Список | pgsql-hackers |
On Sun, Jan 5, 2014 at 10:50 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Fabrízio de Royes Mello <fabriziomello@gmail.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
В списке pgsql-hackers по дате отправления: