Skip site navigation (1) Skip section navigation (2)

Re: tsearch_core for inclusion

From: Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>
To: "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>
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 16:07:22
Message-ID: (view raw or whole thread)
Lists: pgsql-hackers
On Mon, 26 Mar 2007, Florian G. Pflug wrote:

> 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.

It's what people asked for. Think about several sub-projects which share one
database, for example. They all may need different configurations.
It's not difficult to specify schema-qualified name of fts configuration,
but the problem arises when using "simple search", since there is no
way to specify fts name in CREATE INDEX command.

Oleg Bartunov, Research Scientist, Head of AstroNet (,
Sternberg Astronomical Institute, Moscow University, Russia
Internet: oleg(at)sai(dot)msu(dot)su,
phone: +007(495)939-16-83, +007(495)939-23-83

In response to

pgsql-hackers by date

Next:From: Joshua D. DrakeDate: 2007-03-26 16:07:29
Subject: Re: Time to package 8.2.4
Previous:From: Dave PageDate: 2007-03-26 16:06:04
Subject: Re: notification payloads

Privacy Policy | About PostgreSQL
Copyright © 1996-2015 The PostgreSQL Global Development Group