From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew McMillan <andrew(at)catalyst(dot)net(dot)nz> |
Cc: | Cath Lawrence <Cath(dot)Lawrence(at)anu(dot)edu(dot)au>, pgsql-novice(at)postgresql(dot)org |
Subject: | Re: Upgrade function problem - c language |
Date: | 2004-01-10 00:11:31 |
Message-ID: | 3224.1073693491@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-novice |
Andrew McMillan <andrew(at)catalyst(dot)net(dot)nz> writes:
> On Thu, 2004-01-08 at 14:05, Cath Lawrence wrote:
>> me,and yet this does seem to be relevant, because if I try it as
>> userpostgres, I get a different error:
>> pg_restore -O -d cbisdb SampleTableChange.tar
>> pg_restore: [archiver (db)] could not execute query: ERROR:
>> function"plpgsql_call_handler" already exists with same argument types
> Hi Cath,
> I see this all the time doing restores.
> I think there are some situations (on Debian, at least) where pl/pgsql
> gets added to the template1 database. Once that happens you will always
> have to do a "DROP LANGUAGE plpgsql CASCADE" after creating the database
> and before restoring your dump.
The correct way to avoid this issue is to create the database you are
about to restore into as a clone of template0, not template1.
$ createdb -T template0 cbisdb
$ pg_restore -O -d cbisdb SampleTableChange.tar
You can get away without this fine point only so long as you don't add
any site-local objects to template1. plpgsql is just the most common
example of a site-local object you might want to add there ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | sibu xolo | 2004-01-10 01:55:44 | unsubscribe |
Previous Message | Andrew McMillan | 2004-01-09 23:58:55 | Re: Upgrade function problem - c language |