Date: Tue, 7 Nov 2017 05:51:35 -0700 (MST)
From: =?UTF-8?Q?Jan_Przemys=C5=82aw_W=C3=B3jcik?=
 <jan.przemyslaw.wojcik@gmail.com>
To: pgsql-bugs@postgresql.org
Message-ID: <1510059095836-0.post@n3.nabble.com>
In-Reply-To: 
 <CAPpHfdsDtQJ+pYfapH7GMt9n4RLByKMzHEBWcPL99C_g+rkUKQ@mail.gmail.com>
References: 
 <CY4PR17MB13207ED8310F847CF117EED0D85A0@CY4PR17MB1320.namprd17.prod.outlook.com>
 <20171028082225.GA2157@arthur.localdomain>
 <CAPpHfdtz4a9dTxp-Fpem8uBdSBuOQV_i2xuFyL1tG6zM6nAkpg@mail.gmail.com>
 <CA+YsLFp9scUNjjfYJC=84V9o-ZB66GWPq3e_Jveqs1bNejA4qA@mail.gmail.com>
 <CAPpHfdsDtQJ+pYfapH7GMt9n4RLByKMzHEBWcPL99C_g+rkUKQ@mail.gmail.com>
Subject: Re: Fwd: pg_trgm word_similarity inconsistencies or bug
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
Sender: pgsql-bugs-owner@postgresql.org

Hi,

my statement about the function usefulness was probably too categorical,
though I had in mind the current name of the function.=20

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.

------
Jan Przemys=C5=82aw W=C3=B3jcik=20


--
Sent from: http://www.postgresql-archive.org/PostgreSQL-bugs-f2117394.html


--=20
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs