From: | Artur Zakirov <a(dot)zakirov(at)postgrespro(dot)ru> |
---|---|
To: | emre(at)hasegeli(dot)com |
Cc: | Artur Zakirov <a(dot)zakirov(at)postgrespro(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: FTS Configuration option |
Date: | 2016-10-12 22:00:17 |
Message-ID: | CAKNkYnygixjsO9g=-61D4eHvF=6AoQN=e+aaQTVoMQf2beMEHQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Thank you for sharing your thoughts!
2016-10-12 15:08 GMT+03:00 Emre Hasegeli <emre(at)hasegeli(dot)com>:
> However then the stemmer doesn't do a good job on those words, because
> the changed characters are important for the language. What I really
> needed was something like this:
>
>> ALTER TEXT SEARCH CONFIGURATION turkish
>> ALTER MAPPING FOR asciiword, asciihword, hword_asciipart, word, hword, hword_part
>> WITH (fix_mistyped_characters AND (turkish_hunspell OR turkish_stem) AND unaccent);
Your syntax looks more flexible and prettier than with JOIN option. As
I understand there are three steps here. On each step a dictionary
return a lexeme and pass it to next dictionary. If dictionary return
NULL then the processing will interrupt.
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.
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.
Of course if this syntax will be implemented, old syntax with commas
also should be maintained.
--
Artur Zakirov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2016-10-12 22:04:32 | Re: munmap() failure due to sloppy handling of hugepage size |
Previous Message | Tom Lane | 2016-10-12 21:27:31 | Re: Add PGDLLEXPORT to PG_FUNCTION_INFO_V1 |