Re: tsearch_core for inclusion

From: "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>
To: Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>
Cc: Teodor Sigaev <teodor(at)sigaev(dot)ru>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: tsearch_core for inclusion
Date: 2007-03-26 15:57:29
Message-ID: 4607ED69.9030401@phlo.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dave Page 2007-03-26 16:06:04 Re: notification payloads
Previous Message Andrew Dunstan 2007-03-26 15:30:33 notification payloads