Re: Spurious error messages from pg_restore

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.
>
>

In response to

Browse pgsql-general by date

  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