Re: tsearch_core for inclusion - Mailing list pgsql-hackers

From Florian G. Pflug
Subject Re: tsearch_core for inclusion
Date
Msg-id 4607ED69.9030401@phlo.org
Whole thread Raw
In response to Re: tsearch_core for inclusion  (Oleg Bartunov <oleg@sai.msu.su>)
Responses Re: tsearch_core for inclusion  (Oleg Bartunov <oleg@sai.msu.su>)
List pgsql-hackers
Oleg Bartunov wrote:
> On Fri, 23 Mar 2007, Florian G. Pflug wrote:
> 
>> Teodor Sigaev wrote:
>>> For given schema and server's locale, it's possible to have several 
>>> FTS configurations, but the only one (with special flag enabled)
>>> could be used as default. Current (active) FTS configuration contains
>>> in GUC variable tsearch_conf_name. If it's not defined, then FTS 
>>> configuration
>>> is looked in search_path to match server's locale with default flag 
>>> enabled.
>>
>> Isn't the real problem that only _one_ configuration per locale should
>> be marked as DEFAULT at any time, no matter what schema it is in?
> 
> I'm not sure I understand you correct (a bit complex :), but it's allowed
> to have only _one_ DEFAULT configuration per schema/per locale. So,
> visibility is defined by search_path for given locale.

Yes, but why is that needed? Wouldn't one DEFAULT configuration
per database be sufficient, and avoid the search_path problems?

Sorry if I'm being stupid - I just can't see what having a different
DEFAULT configuration per schema buys you.

greetings, Florian Pflug


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: notification payloads
Next
From: Dave Page
Date:
Subject: Re: notification payloads