Re: Subtle pg_dump problem... - Mailing list pgsql-hackers

From Christopher Kings-Lynne
Subject Re: Subtle pg_dump problem...
Date
Msg-id 40A24117.9060900@familyhealth.com.au
Whole thread Raw
In response to Re: Subtle pg_dump problem...  (Oleg Bartunov <oleg@sai.msu.su>)
Responses Re: Subtle pg_dump problem...  (Oleg Bartunov <oleg@sai.msu.su>)
List pgsql-hackers
> No problem,

Actually, I did some more testing and I properly understand the problem 
now - and it won't happen in the general restoring case.

What fails is if you "pg_dump -a" to just dump the DATA from a table 
containing a tsearch2 trigger that is in a different schema.

Then you delete all the rows from the table.

Then you try to execute the sql script created from pg_dump to restore 
the data.

It will fail because the sql script will automatically set the 
search_path to public, pg_catalog.  And then as the COPY command inserts 
each row, it will fail immediately as the tsearch2 trigger will not be 
able to find its config table.

Does that make sense?

Chris


pgsql-hackers by date:

Previous
From: Christopher Kings-Lynne
Date:
Subject: Re: Subtle pg_dump problem...
Next
From: Oleg Bartunov
Date:
Subject: Re: Subtle pg_dump problem...