From: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Subtle pg_dump problem... |
Date: | 2004-05-13 01:58:17 |
Message-ID: | 40A2D639.4060406@familyhealth.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> 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.
I think a better solution is to change tsearch2 to have two assumptions:
1. All tsearch2 objects will be loaded in the same schema, name not
important.
2. When an object foo is called and needs to refer to another object
bar, it should assume that bar exists in the same schema as foo, and NOT
in the current search_path.
Chris
From | Date | Subject | |
---|---|---|---|
Next Message | Larry Rosenman | 2004-05-13 02:14:38 | Re: threads stuff/UnixWare |
Previous Message | Bruce Momjian | 2004-05-13 01:55:40 | Re: threads stuff/UnixWare |