Re: BUG #18636: I am seeing a difference in behavior between 13.12 and 15.6 for full text searching

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: Raw Message | Whole Thread | 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

In response to

Browse pgsql-bugs by date

  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