From: | Evan Martin <postgresql(at)realityexists(dot)net> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Spurious error messages from pg_restore |
Date: | 2013-09-04 17:08:06 |
Message-ID: | 522768F6.8000209@realityexists.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
I'm not sure I see the problem. The rule name is only unique within the
table, so it would not replace a rule on a different table (or view, as
is the case here) than the one being restored. Functions names should be
schema-qualified and if I'm restoring a function from a backup I would
want any existing function with the same signature to be overwritten.
On 04.09.2013 18:20, Adrian Klaver wrote:
> On 09/04/2013 07:02 AM, Evan Martin wrote:
>
>> Also, even without --clean I get 3 errors:
>>
>> pg_restore: [archiver (db)] Error while PROCESSING TOC:
>> pg_restore: [archiver (db)] Error from TOC entry 6755; 2618 4417788 RULE
>> geometry_columns_delete em
>> pg_restore: [archiver (db)] could not execute query: ERROR: rule
>> "geometry_columns_delete" for relation "geometry_columns" already exists
>> Command was: CREATE RULE geometry_columns_delete AS ON DELETE TO
>> geometry_columns DO INSTEAD NOTHING;
>>
>> (and same for "geometry_columns_insert" and "geometry_columns_update")
>>
>> This is probably because I have PostGIS installed as an extension (in
>> both the source and target databases), which creates those rules. Could
>> pg_restore use CREATE OR REPLACE whenever possible to avoid this?
>
> I could see where CREATE OR REPLACE would lead to hidden corruption.
> It is in entirely possible for a RULE or FUNCTION to have the same
> name in different databases, but have different code under the name.
> Blindly REPLACEing would get you past the error messages, however it
> is possible that it leads to all sorts of headaches later.
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Trigve Siver | 2013-09-04 17:10:14 | Re: FETCH FORWARD 0 and "cursor can only scan forward" error |
Previous Message | Tom Lane | 2013-09-04 17:04:38 | Re: FETCH FORWARD 0 and "cursor can only scan forward" error |