| From: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> |
|---|---|
| To: | Oleg Bartunov <oleg(at)sai(dot)msu(dot)su> |
| Cc: | Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Subtle pg_dump problem... |
| Date: | 2004-05-12 15:21:59 |
| Message-ID: | 40A24117.9060900@familyhealth.com.au |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Oleg Bartunov | 2004-05-12 15:22:17 | Re: Subtle pg_dump problem... |
| Previous Message | Christopher Kings-Lynne | 2004-05-12 15:04:02 | Re: Subtle pg_dump problem... |