Re: BUG #15285: Query used index over field with ICU collation in some cases wrongly return 0 rows - Mailing list pgsql-bugs

From Jehan-Guillaume de Rorthais
Subject Re: BUG #15285: Query used index over field with ICU collation in some cases wrongly return 0 rows
Date
Msg-id 20200907152739.0fd6a12a@firost
Whole thread Raw
In response to Re: BUG #15285: Query used index over field with ICU collation in some cases wrongly return 0 rows  ("Daniel Verite" <daniel@manitou-mail.org>)
Responses Re: BUG #15285: Query used index over field with ICU collation in some cases wrongly return 0 rows
List pgsql-bugs
On Thu, 03 Sep 2020 13:49:24 -0400
Tom Lane <tgl@sss.pgh.pa.us> wrote:

>     =?UTF-8?Q?=D0=BE=D0=B2=D1=87=D0=B5=D0=BD=D0=BA=D0=BE" ?=
>     <roman.lytovchenko@gmail.com>,
>     "PostgreSQL mailing lists" <pgsql-bugs@lists.postgresql.org>
> Subject: Re: BUG #15285: Query used index over field with ICU collation in
> some cases wrongly return 0 rows In-reply-to:
> <c00a63d3-f9c3-4222-a659-637232523b30@manitou-mail.org> References:
> <c00a63d3-f9c3-4222-a659-637232523b30@manitou-mail.org> Comments: In-reply-to
> "Daniel Verite" <daniel@manitou-mail.org> message dated "Thu, 03 Sep 2020
> 11:29:15 +0200" Fcc: inbox
> --------

Something broke in this answer, so I try to hook it back to the appropriate
thread.

> "Daniel Verite" <daniel@manitou-mail.org> writes:
> > Now that we know that this collation is problematic, we could remove
> > this example, even if we don't want to go as far as documenting
> > ICU bugs. In fact bug reports used the same name "digitslast", so
> > I wonder if people tried this straight from our doc.  
> 
> If we aren't going to try to work around the bug, I agree that
> removing that example (or replacing it with a less buggy one?)
> is a good idea.

OK.
Please, find a patch in attachment. It removes the buggy collation from doc and
adapt existing ones to keep an example of combination of rules.

> I tend to agree with Peter that trying to work around a bug that
> isn't ours and that we don't fully understand is not going to
> be very productive.  What is the argument, other than observation
> of a small number of test cases, that these other subroutines
> don't have bugs of their own?

What about adding it as a "known bug"/"will not fix" in
https://wiki.postgresql.org/wiki/Todo and link it from the doc in a note bloc? I
strongly feel most user do not know where to find such list of bugs in
PostgreSQL ecosystem.

Regards,

Attachment

pgsql-bugs by date:

Previous
From: Jehan-Guillaume de Rorthais
Date:
Subject: Re: [BUG] plpgsql RETURN QUERY with toasted fields -vs- DROP/TRUNCATE
Next
From: Jehan-Guillaume de Rorthais
Date:
Subject: Re: [BUG v13] Crash with event trigger in extension