Re: BUG #15285: Query used index over field with ICU collation in some cases wrongly return 0 rows
От | Jehan-Guillaume de Rorthais |
---|---|
Тема | Re: BUG #15285: Query used index over field with ICU collation in some cases wrongly return 0 rows |
Дата | |
Msg-id | 20200907152739.0fd6a12a@firost обсуждение исходный текст |
Ответ на | Re: BUG #15285: Query used index over field with ICU collation in some cases wrongly return 0 rows ("Daniel Verite" <daniel@manitou-mail.org>) |
Ответы |
Re: BUG #15285: Query used index over field with ICU collation in some cases wrongly return 0 rows
|
Список | 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,
Вложения
В списке pgsql-bugs по дате отправления: