From: | Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com> |
---|---|
To: | "David E(dot) Wheeler" <david(at)kineticode(dot)com>, David Fetter <david(at)fetter(dot)org>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr> |
Cc: | PostgreSQL-Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Extensions support for pg_dump, patch v27 |
Date: | 2011-01-26 02:54:02 |
Message-ID: | AANLkTi=jscPnm3rr8ynGbeepyCC4iFeVsPvoLm=PzVdm@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jan 26, 2011 at 02:57, David E. Wheeler <david(at)kineticode(dot)com> wrote:
>>> Other than adminpack, I think it makes sense to say that extensions
>>> are not going into pg_catalog…
>>
>> Given this, we should maybe see about either making adminpack part of
>> PostgreSQL's core distribution (probably a good idea) or moving it out
>> of pg_catalog so we don't have an exception to the rule.
>
> +1
I doubt it can solve the real problem.
It is my understanding that we install them in pg_catalog because
they are designed to be installed in template1 for pgAdmin, right?
We have a problem in pg_dump when we install extension modules in
template1. If we create a database, installed functions are copied
from template1. However, they are also dumped with pg_dump unless
they are in pg_catalog. So, we encounter "function already exists"
errors when pg_restore.
Since pg_dump won't dump user objects in pg_catalog, adminpack can
avoid the above errors by installing functions in pg_catalog.
CREATE EXTENSION might have the same issue -- Can EXTENSION work
without errors when we install extensions in template databases?
To avoid errors, pg_dump might need to dump extensions as
"CREATE OR REPLACE EXTENSION" or "CREATE EXTENSION IF NOT EXISTS"
rather than "CREATE EXTENSION".
--
Itagaki Takahiro
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2011-01-26 03:22:42 | Re: ALTER TYPE 2: skip already-provable no-work rewrites |
Previous Message | Fujii Masao | 2011-01-26 02:38:56 | Re: Change pg_last_xlog_receive_location not to move backwards |