Re: FTS Configuration option - Mailing list pgsql-hackers

From Emre Hasegeli
Subject Re: FTS Configuration option
Date
Msg-id CAE2gYzx2N=77NoL80tQC30zm+OhEavdg-DsEkpT_BpXzRohwuQ@mail.gmail.com
Whole thread Raw
In response to Re: FTS Configuration option  (Artur Zakirov <a.zakirov@postgrespro.ru>)
Responses Re: FTS Configuration option  (Artur Zakirov <a.zakirov@postgrespro.ru>)
List pgsql-hackers
> With such syntax we also don't need the TSL_FILTER flag for lexeme. At
> the current time unaccent extension set this flag to pass a lexeme to
> a next dictionary. This flag is used by the text-search parser. It
> looks like a hard coded solution. User can't change this behaviour.

Exactly.

> Maybe also better to use -> instead of AND? AND would has another
> behaviour. I could create the following configuration:
>
> => ALTER TEXT SEARCH CONFIGURATION multi_conf
>     ALTER MAPPING FOR asciiword, asciihword, hword_asciipart,
>     word, hword, hword_part
>     WITH (german_ispell AND english_ispell) OR simple;
>
> which will return both german_ispell and english_ispell results. But
> I'm not sure that this is a good solution.

I see you usecase for AND.  It might indeed be useful.  AND suits well to it.

Maybe THEN can be the keyword instead of -> for pass the results to
subsequent dictionaries.  They are all reserved keywords.  I guess it
wouldn't be a problem to use them.

> Of course if this syntax will be implemented, old syntax with commas
> also should be maintained.

Yes, we should definitely.  The comma can be interpreted either one of
the keywords depending on left hand side dictionary.

I would be glad to review, if you develop this feature.



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: pg_dump, pg_dumpall and data durability
Next
From: Artur Zakirov
Date:
Subject: Re: FTS Configuration option