From: | Emre Hasegeli <emre(at)hasegeli(dot)com> |
---|---|
To: | Artur Zakirov <a(dot)zakirov(at)postgrespro(dot)ru> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: FTS Configuration option |
Date: | 2016-10-13 08:54:15 |
Message-ID: | CAE2gYzx2N=77NoL80tQC30zm+OhEavdg-DsEkpT_BpXzRohwuQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Artur Zakirov | 2016-10-13 09:19:56 | Re: FTS Configuration option |
Previous Message | Michael Paquier | 2016-10-13 08:13:37 | Re: pg_dump, pg_dumpall and data durability |