TC39 ECMA402
2023-08-21
plaintext logs
prev next
source on github
09:27
<hsivonen>
> Moreover, it's bad that the distinction isn't visible in the typical CI locale of en-US.
Can you check the resolved options to get the locale?
Possibly, yeah, if one goes looking for it, instead of just testing sort behavior.
09:28
<hsivonen>
Everything in Intl falls back to the host locale… I think that’s the extent of the rationale.
Thanks.
09:30
<hsivonen>
If we wanted to work on Intl.Collator, we should probably address the thing where the design forces a bunch of recalculation of the collation key to do any sorting…
Unlikely. According to ICU4C docs, the number of comparisons that you need to do to amortize the collation key generation is high, and collation keys are rarely appropriate. (FWIW, it appears that even SQLite's ICU4C mode sorts without stored collation keys even though the use case for stored collation keys is "databases")
15:30
<sffc>
Let's please not use locale sensitive sorting in a database. My team just spent a quarter making a special version of ICU to help a database team not corrupt their data when upgrading our library.
21:50
<justingrant>

(FWIW, it appears that even SQLite's ICU4C mode sorts without stored collation keys even though the use case for stored collation keys is "databases")

My team just spent a quarter making a special version of ICU to help a database team not corrupt their data when upgrading our library.

By "stored collation key" do you mean that when a column is stored with a particular collation, then (as an implementation detail) a collation key is also stored along with that column's data?

sffc was this an existing 3rd-party DBMS like Oracle or MySQL? Or was it a custom internal Google thing?

If the former, then I'd be curious to learn if any RDBMS does that. AFAIK, I/O is much more expensive than CPU in most modern platforms, so it seems fine to recalculate a collation key whenever sorting or comparing while running a query or when building a persisted index. Yes, it's slower, but if perf is a problem then building an index is typically the right solution rather than optimizing table scans.