Re: Flexible configuration for full-text search

On Thu, Nov 29, 2018 at 02:02:16PM +0100, Dmitry Dolgov wrote: > Maybe it would be better if you or some of your colleagues (Alexander, > Arthur?) > will post this new version, because the current one has some conflicts - so it > would be easier for a reviewers. For now I'll move it to the next

Re: Flexible configuration for full-text search

> On Wed, Aug 29, 2018 at 10:38 AM Aleksandr Parfenov > wrote: > > On Tue, 28 Aug 2018 12:40:32 +0700 > Aleksandr Parfenov wrote: > > >On Fri, 24 Aug 2018 18:50:38 +0300 > >Alexander Korotkov wrote: > >>Agreed, backward compatibility is important here. Probably we should > >>leave old

Re: Flexible configuration for full-text search

Aleksandr Parfenov writes: > As I wrote few weeks ago, there is a issue with stopwords processing in > proposed syntax for full-text configurations. I want to separate word > normalization and stopwords detection to two separate dictionaries. The > problem is how to configure stopword detection

Re: Flexible configuration for full-text search

Hello hackers! As I wrote few weeks ago, there is a issue with stopwords processing in proposed syntax for full-text configurations. I want to separate word normalization and stopwords detection to two separate dictionaries. The problem is how to configure stopword detection dictionary. The

Re: Flexible configuration for full-text search

On Tue, 28 Aug 2018 12:40:32 +0700 Aleksandr Parfenov wrote: >On Fri, 24 Aug 2018 18:50:38 +0300 >Alexander Korotkov wrote: >>Agreed, backward compatibility is important here. Probably we should >>leave old dictionaries for that. But I just meant that if we >>introduce new (better) way of

Re: Flexible configuration for full-text search

On Fri, 24 Aug 2018 18:50:38 +0300 Alexander Korotkov wrote: >Agreed, backward compatibility is important here. Probably we should >leave old dictionaries for that. But I just meant that if we >introduce new (better) way of stop words handling and encourage users >to use it, then it would look

Re: Flexible configuration for full-text search

On Fri, Aug 24, 2018 at 1:13 AM Tom Lane wrote: > Alexander Korotkov writes: > > On Fri, Apr 6, 2018 at 10:52 AM Aleksandr Parfenov > > wrote: > >> The key point of the patch is to process stopwords the same way as > >> others at the level of the PostgreSQL internals and give users an > >>

Re: Flexible configuration for full-text search

Alexander Korotkov writes: > On Fri, Apr 6, 2018 at 10:52 AM Aleksandr Parfenov > wrote: >> The key point of the patch is to process stopwords the same way as >> others at the level of the PostgreSQL internals and give users an >> instrument to process them in a special way via configurations.

Re: Flexible configuration for full-text search

On Fri, Apr 6, 2018 at 10:52 AM Aleksandr Parfenov wrote: > On Thu, 5 Apr 2018 17:26:10 +0300 > Teodor Sigaev wrote: > > 4) Initial approach suggested to distinguish three state of > > dictionary result: null (unknown word), stopword and usual word. Now > > only two, we lost possibility to catch

Re: Flexible configuration for full-text search

Hi, Aleksandr! On Mon, Jul 9, 2018 at 10:26 AM Aleksandr Parfenov < a.parfe...@postgrespro.ru> wrote: > A new version of the patch in the attachment. There are no changes since > the last version except refreshing it to current HEAD. > I took a look at this patch. It applied cleanly, but

Re: Flexible configuration for full-text search

Hi, On 2018-04-05 17:26:10 +0300, Teodor Sigaev wrote: > Some notices: > > 0) patch conflicts with last changes in gram.y, conflicts are trivial. > > 1) jsonb in catalog. I'm ok with it, any opinions? > > 2) pg_ts_config_map.h, "jsonb mapdicts" isn't decorated with #ifdef >

Re: Flexible configuration for full-text search

Some notices: 0) patch conflicts with last changes in gram.y, conflicts are trivial. 1) jsonb in catalog. I'm ok with it, any opinions? 2) pg_ts_config_map.h, "jsonb mapdicts" isn't decorated with #ifdef CATALOG_VARLEN like other varlena columns in catalog. It it's right, pls, explain

Re: Flexible configuration for full-text search

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: tested, passed Documentation:tested, passed LGTM. The new status of this patch is: Ready for Committer

Re: Flexible configuration for full-text search

The following review has been posted through the commitfest application: make installcheck-world: not tested Implements feature: not tested Spec compliant: not tested Documentation:not tested Unfortunately this patch doesn't apply anymore:

Re: [HACKERS] Flexible configuration for full-text search

On Tue, 26 Dec 2017 13:51:03 +0300 Arthur Zakirov wrote: > On Mon, Dec 25, 2017 at 05:15:07PM +0300, Aleksandr Parfenov wrote: > > Is I understood users need to rewrite their configurations if they > use unaccent dictionary, for example. It is not good I think. Users >

Re: [HACKERS] Flexible configuration for full-text search

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 >

Re: [HACKERS] Flexible configuration for full-text search

Hi Arthur, Thank you for the review. On Thu, 21 Dec 2017 17:46:42 +0300 Arthur Zakirov wrote: > I noticed that there are typos in the documentation. And I think it > is necessary to keep information about previous sintax. The syntax > will be supported anyway. For

Re: [HACKERS] Flexible configuration for full-text search

Hello, On Tue, Dec 19, 2017 at 05:31:09PM +0300, Aleksandr Parfenov wrote: > > 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. > I looked the patch a little bit. The patch is applied and

Re: [HACKERS] Flexible configuration for full-text search

On Tue, Nov 7, 2017 at 3:18 PM, Aleksandr Parfenov wrote: > On Mon, 6 Nov 2017 18:05:23 +1300 > Thomas Munro wrote: > >> On Sat, Oct 21, 2017 at 1:39 AM, Aleksandr Parfenov >> wrote: >> > In attachment updated