On Fri, Aug 24, 2018 at 1:13 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Alexander Korotkov <a.korotkov@postgrespro.ru> writes:
> > On Fri, Apr 6, 2018 at 10:52 AM Aleksandr Parfenov
> > <a.parfenov@postgrespro.ru> 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.
>
> > If we're going to do it that way by providing separate dictionaries
> > for stop words, then I think we should also make it for builtin
> > dictionaries and configurations. So, I think this patch should also
> > split builtin dictionaries into stemmers and stop word dictionaries,
> > and provide corresponding configuration over them. It would be also
> > needed to perform some benchmarking to show that new way of defining
> > configurations is not worse than previous way in the performance.
>
> I'm hesitant about the backwards-compatibility aspects of this.
> Yes, we could set up the standard text search configurations to still
> work the same as before, but how will you do it without breaking existing
> custom configurations that use those dictionaries?
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 strange if default configurations work
the old way...
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company