Re: Collation version tracking for macOS

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: Collation version tracking for macOS
Дата
Msg-id CAH2-WzmXFVw6wAtgLo+0ggin===9TOG8OZC9VorHCu9W7y4Kew@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Collation version tracking for macOS  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Collation version tracking for macOS  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Collation version tracking for macOS  (Jeremy Schneider <schneider@ardentperf.com>)
Список pgsql-hackers
On Tue, Jun 7, 2022 at 12:37 PM Robert Haas <robertmhaas@gmail.com> wrote:
> It's true that we don't have any false positives right now, but we
> also have no true positives. Even a stopped clock is right twice a
> day, but not in a useful way. People want to be notified when a
> problem might exist, even if sometimes it doesn't actually.

Collations by their very nature are unlikely to change all that much.
Obviously they can and do change, but the details are presumably
pretty insignificant to a native speaker. Stands to reason that the
issue (which is fundamentally a problem for natural language experts)
would have been resolved far sooner if there really was a significant
controversy about something that tends to come up often.

It's pretty clear that glibc as a project doesn't take the issue very
seriously, because they see it as a problem of the GUI sorting a table
in a way that seems slightly suboptimal to scholars of a natural
language. Clearly that isn't actually a big deal. But the latent
possibility of wrong answers to queries is a very big deal. Both are
true. It's just a matter of priorities in each case.

I agree that "false positive" is not a valid way of describing a
breaking change in a Postgres collation that happens to not affect one
index in particular, due to the current phase of the moon. It's
probably very likely that most individual indexes that we warn about
will be so-called false positives. I bet Postgres that there are many
near-misses that we never get to hear about already. That's rather
beside the point. The index must be assumed to be corrupt.

-- 
Peter Geoghegan



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Collation version tracking for macOS
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Sudden database error with COUNT(*) making Query Planner crashes: variable not found in subplan target list