On 13.10.2016 11:54, Emre Hasegeli wrote:
>
>> 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.
I agree with THEN. It is better than using -> I think. I suppose it
wouldn't be a problem too. I think it is necessary to fix gram.y and
implement logic with OR, AND and THEN.
>
>> 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.
>
Then I will develop it :). But I suppose I can do it a few days or weeks
later, because I have other tasks with higher priority.
BTW, I've already implemented USING option a few weeks before
https://github.com/select-artur/postgres/tree/join_tsconfig . But of
course it is not useful now.
--
Artur Zakirov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company
