| From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
|---|---|
| To: | glenncipolla(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #18636: I am seeing a difference in behavior between 13.12 and 15.6 for full text searching |
| Date: | 2024-09-27 14:00:08 |
| Message-ID: | cdabb7d6326326388a2914cc4d30cfc6d5969019.camel@cybertec.at |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Fri, 2024-09-27 at 13:28 +0000, PG Bug reporting form wrote:
> The following bug has been logged on the website:
>
> Bug reference: 18636
> Logged by: Glenn Cipolla
> Email address: glenncipolla(at)gmail(dot)com
> PostgreSQL version: 13.12
> Operating system: Ubuntu 11.4
> Description:
>
> The following query
>
> select to_tsvector('simple','RG147SW RG14 Greenham Road Newbury West
> Berkshire')
> @@ to_tsquery('simple', 'gree,west:*');
>
> Returns false in PG 15.6, but returns true in pg 13.12. In 15.6 the code
> returns 'gree:* <-> 'west':*.
> In 13.12 it returns 'gree:* & 'west':*
>
> This article says the 13.12 behavior was a bug that was fixed in 14.x
> (https://akorotkov.github.io/blog/2021/05/22/pg-14-query-parsing/)
>
> I have a dev team about to change their code to handle the new <->. Before
> they do that, I would like a confirmation that this functionality is
> 1. A bug
> 2. The new functionality will not change back in newer versions. Do you
> intent to stick with the <-> return value?
We intend to stick with the way it works now... unless somebody comes
up with a very good reason why that behavior is buggy and worth the
compatibility pain the fix incurs.
From the commit message, the reason for 0c4f355c6a was that
to_tsquery('simple', 'pg_class catalog')
used to return
'( pg & class ) <-> catalog'
That is nonsensical, because both "pg" and "class" would have to
occur right before "catalog", which cannot be.
That seemed buggy enough to warrant a compatibility break.
We cannot promise that no more bugs will be found whose fixes will
break compatibility, but we have every intention not to introduce
incompatibilities wantonly.
Yours,
Laurenz Albe
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PG Bug reporting form | 2024-09-27 14:31:54 | BUG #18637: CREATE INDEX won't look up operator classes in search_path if PARTITION BY is specified |
| Previous Message | David G. Johnston | 2024-09-27 13:47:20 | Re: BUG #18635: " $libdir/adminpack could not be loaded" error with pg_upgrade to PostgreSQL17 |