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

From Arthur Zakirov
Subject Re: [HACKERS] Flexible configuration for full-text search
Date
Msg-id 20171226105102.GA3225@zakirov.localdomain
Whole thread Raw
In response to Re: [HACKERS] Flexible configuration for full-text search  (Aleksandr Parfenov <a.parfenov@postgrespro.ru>)
Responses Re: [HACKERS] Flexible configuration for full-text search
List pgsql-hackers
On Mon, Dec 25, 2017 at 05:15:07PM +0300, Aleksandr Parfenov wrote:
> 
> In the current version of the patch, configurations written in old
> syntax are rewritten into the same configuration in the new syntax.
> Since new syntax doesn't support a TSL_FILTER, it was removed from the
> documentation. It is possible to store configurations written in old
> syntax in a special way and simulate a TSL_FILTER behavior for them.
> But it will lead to maintenance of two different behavior of the FTS
> depends on a version of the syntax used during configuration. Do you
> think we should keep both behaviors?

Is I understood users need to rewrite their configurations if they use unaccent dictionary, for example.
It is not good I think. Users will be upset about that if they use only old configuration and they don't need new
configuration.

From my point of view it is necessary to keep old configuration syntax.

> 
> Columns' 'dictionaries' and 'dictionary' type were changed to text
> because after the patch the configuration may be not a plain array of
> dictionaries but a complex expression tree. In the column
> 'dictionaries' the result is textual representation of configuration
> and it is the same as a result of \dF+ description of the configuration.

Oh, I understood.

> 
> I decide to rename newly added column to 'configuration' and keep
> column 'dictionaries' with an array of all dictionaries used in
> configuration (no matter how). Also, I fixed a bug in 'command' output
> of the ts_debug in some cases.

Maybe it would be better to keep the 'dictionary' column name? Is there a reason why it was renamed to 'command'?

> 
> Additionally, I added some examples to documentation regarding
> multilingual search and combination of exact and linguistic-aware
> search and fixed typos.

Great!


-- 
Arthur Zakirov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company


pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: pgsql: Add parallel-aware hash joins.
Next
From: "Daniel Verite"
Date:
Subject: Re: General purpose hashing func in pgbench