Re: Subtle pg_dump problem...

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

In response to

Responses

Browse pgsql-hackers by date

  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