On Wed, 12 May 2004, Christopher Kings-Lynne wrote:
> > 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?
Hmm, what other hackers thinks ? This is not just a tsearch2 problem,
it could happens with any such kind of things, like defining user defined
type in one scheme, using it in another, dumping separate data.
Could pg_dump be enough smart to set search_path properly ?
>
> Chris
>
Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
