Re: [HACKERS] Flexible configuration for full-text search - Mailing list pgsql-hackers

From Aleksandr Parfenov
Subject Re: [HACKERS] Flexible configuration for full-text search
Date
Msg-id 20171219173109.7d21e0ef@asp437-24-g082ur
Whole thread Raw
In response to Re: [HACKERS] Flexible configuration for full-text search  (Emre Hasegeli <emre@hasegeli.com>)
Responses Re: [HACKERS] Flexible configuration for full-text search
List pgsql-hackers
Hi,

On Tue, 31 Oct 2017 09:47:57 +0100
Emre Hasegeli <emre@hasegeli.com> wrote:

> I am glad you liked it.  Though, I think we should get approval from
> more senior community members or committers about the syntax, before
> we put more effort to the code.

I postpone a new version of the patch in order to wait for more
feedback, but I think now is the time to send it to push discussion
further.

I keep in mind all the feedback during reworking a patch, so the FTS
syntax and behavior changed since previous one. But I'm not sure about
one last thing:

> CASE polish_stopword    -- stopword counting
>     WHEN NO MATCH THEN polish_isspell
> END
> 
> Do you think it is possible?

If we will count tokens in such a case, any dropped words will be
counted too. For example:

CASE banned_words
    WHEN NO MATCH THEN some_dictionary
END

And I'm not sure about that behavior due to implicit use of the
token produced by 'banned_words' dictionary in the example. In the third
version of patch I keep the behavior without an implicit use of
tokens for counting.

The new version of the patch is in attachment as well as a
little README file with a description of changes in each file. Any
feedback is welcome.

-- 
Aleksandr Parfenov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company
Attachment

pgsql-hackers by date:

Previous
From: Marina Polyakova
Date:
Subject: Re: WIP Patch: Pgbench Serialization and deadlock errors
Next
From: Paul Ramsey
Date:
Subject: Re: MemoryContextCreate change in PG 11 how should contexts be created