Re: Fwd: [BUGS] pg_trgm word_similarity inconsistencies or bug - Mailing list pgsql-bugs

From Robert Haas
Subject Re: Fwd: [BUGS] pg_trgm word_similarity inconsistencies or bug
Date
Msg-id CA+Tgmobksqi+Kh2=NZarEhnSUAudY=3oc+K8HjqSRvytbw7cnQ@mail.gmail.com
Whole thread Raw
In response to Re: Fwd: [BUGS] pg_trgm word_similarity inconsistencies or bug  (Jan Przemysław Wójcik <jan.przemyslaw.wojcik@gmail.com>)
Responses Re: Fwd: [BUGS] pg_trgm word_similarity inconsistencies or bug  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
Re: Fwd: [BUGS] pg_trgm word_similarity inconsistencies or bug  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
List pgsql-bugs
On Tue, Nov 7, 2017 at 7:51 AM, Jan Przemysław Wójcik
<jan.przemyslaw.wojcik@gmail.com> wrote:
> I'm afraid that creating a function that implements quite different
> algorithms depending on a global parameter seems very hacky and would lead
> to misunderstandings. I do understand the need of backward compatibility,
> but I'd opt for the lesser evil. Perhaps a good idea would be to change the
> name to 'substring_similarity()' and introduce the new function
> 'word_similarity()' later, for example in the next major version release.

That breaks things for everybody using word_similarity() currently.
If the previous discussion of this topic concluded that
word_similarity() was an OK name despite being a slight misnomer, I
don't think we should change our mind now.  Instead the new function
can be called something which makes the difference clear, e.g.
strict_word_similarity(), and the old function can remain as it is.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-bugs by date:

Previous
From: François CHAHUNEAU
Date:
Subject: Re: [BUGS] pg_trgm word_similarity inconsistencies or bug
Next
From: Jan Schulz
Date:
Subject: Re: BUG #14948: cost overflow