Re: Collation version tracking for macOS

Поиск
Список
Период
Сортировка
От Jeremy Schneider
Тема Re: Collation version tracking for macOS
Дата
Msg-id 127AA2FF-F097-464D-B8D6-761141EF504D@ardentperf.com
обсуждение исходный текст
Ответ на Re: Collation version tracking for macOS  (Jim Nasby <nasbyj@amazon.com>)
Ответы Re: Collation version tracking for macOS  (Thomas Munro <thomas.munro@gmail.com>)
Список pgsql-hackers
> On Jun 6, 2022, at 17:10, Jim Nasby <nasbyj@amazon.com> wrote:
> Ignoring broken backups, segfaults and data corruption as a "rant" implies that we simply throw in the towel and
tellusers to suck it up or switch engines. 


Well now, let’s be clear, I was the one who called my email a “rant”.  🙂

And I do apologize for that - it was grumpy and impulsive and Tom isn’t wrong that rants don’t usually help move things
forward.

Thomas - thanks for the link back to one of the threads. I spent some time reading through that and it’s a lot of
material;I haven’t read the whole thread yet. If you have some others that would also be particularly good background,
letme know. I’m doing a chunk of this in my spare time at the moment, but I do want to keep getting more up to speed. I
waspulled into a bunch of various things related to PostgreSQL and ICU and collation and OS’s over the past couple
years,so I learned a lot from on-the-ground experience and I am interested in trying to get a little more involved in
theconversation here. 

Personally, I really do think there should at least be an *option* to tell the DB to fully error rather than just warn
onversion mismatch. Correctness matters to many users, and being able to *trust* string comparisons are correct is
prettydamn fundamental all throughout a database. It really doesn’t get any more basic and the potential for bad things
tohappen is pretty astronomical, if you can’t trust those. I understand the consternation about dealing with upgrades
oflarge & busy databases, but I’m still surprised that the community consensus arrived at the present behavior, and I
havea lot of reading to do, to really understand how that happened and where the dialogue is today. 

Multiple versions of ICU sounds nice for users who need real linguistic collation (like what Oracle and DB2 offer), but
Istill feel like there needs to be a super simple basic “pseudo-linguistic” collation baked in, that’s “good enough”
for99% of users and that is guaranteed to be the same everywhere on every platform and just won’t ever change. I think
glibcneeds to be phased out somehow. At a minimum, not the default for new users… to stop the bleeding. If MySQL wasn’t
GPLthen I’d say to just copy their collations. I’d be reluctant to spend too much time on a POC now though, it feels
likemy idea is the outlier and the general PG hacker consensus would be to reject this idea. (But maybe I’m wrong?) 

Anyway, again, apologies for my pants-on-fire email last week. I hope I can enjoy a few beers someday - or coffee for
thenon-drinkers - with a few other PG collation nerds (which I never set out to be, but it may have befallen me <g>). 

-Jeremy


Sent from my TI-83




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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Collation version tracking for macOS
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: Collation version tracking for macOS