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

From Tom Lane
Subject Re: Subtle pg_dump problem...
Date
Msg-id 26087.1084380262@sss.pgh.pa.us
Whole thread Raw
In response to Re: Subtle pg_dump problem...  (Oleg Bartunov <oleg@sai.msu.su>)
Responses Re: Subtle pg_dump problem...  (Christopher Kings-Lynne <chriskl@familyhealth.com.au>)
List pgsql-hackers
Oleg Bartunov <oleg@sai.msu.su> writes:
> 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  ?

It could not.  I think the fundamental point here is that it is a real
bad idea for the tsearch routines to make any assumptions about the
current search path.  What I would suggest is that the internal objects
used by the tsearch routines (such as pg_ts_cfg) should be required to
live in a specific schema ("tsearch2" seems like a good name) and that
all the internal references inside the tsearch functions should be fully
qualified names.

You could perhaps make this private schema name be selectable at the
time tsearch is built ... but I'm not sure it's worth the trouble.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Marc G. Fournier"
Date:
Subject: Re: threads stuff/UnixWare
Next
From: Larry Rosenman
Date:
Subject: Re: threads stuff/UnixWare