Thread: [18] separate collation and ctype versions, and cleanup of pg_database locale fields
[18] separate collation and ctype versions, and cleanup of pg_database locale fields
From
Jeff Davis
Date:
Definitions:
- collation is text ordering and comparison
- ctype affects case mapping (e.g. LOWER()) and pattern
matching/regexes
Currently, there is only one version field, and it represents the
version of the collation. So, if your provider is libc and datcollate
is "C" and datctype is "en_US.utf8", then the datcollversion will
always be NULL. Other providers use datcolllocale, which is only one
field, so it doesn't matter.
Given the discussion here:
https://www.postgresql.org/message-id/1078884.1721762815@sss.pgh.pa.us
it seems like it may be a good idea to version collation and ctype
separately. The ctype version is, more or less, the Unicode version,
and we know what that is for the builtin provider as well as ICU.
(Aside: ICU could theoretically report the same Unicode version and
still make some change that would affect us, but I have not observed
that to be the case. I use exhaustive code point coverage to test that
our Unicode functions return the same results as the corresponding ICU
functions when the Unicode version matches.)
Adding more collation fields is getting to be messy, though, because
they all have to be present in pg_database, as well. It's hard to move
those fields into pg_collation, because that's not a shared catalog, so
that could cause problems with CREATE/ALTER DATABASE. Is it worth
thinking about how we can clean this up, or should we just put up with
the idea that almost half the fields in pg_database will be locale-
related?
Regards,
Jeff Davis
Re: [18] separate collation and ctype versions, and cleanup of pg_database locale fields
From
Jeff Davis
Date:
On Thu, 2024-07-25 at 13:29 -0700, Jeff Davis wrote:
> it may be a good idea to version collation and ctype
> separately. The ctype version is, more or less, the Unicode version,
> and we know what that is for the builtin provider as well as ICU.
Attached a rough patch for the purposes of discussion. It tracks the
ctype version separately, but doesn't do anything with it yet.
The main problem is that it's one more slightly confusing thing to
understand, especially in pg_database because it's the ctype version of
the database default collation, not necessarily datctype.
Maybe we can do something with the naming or catalog representation to
make this more clear?
Regards,
Jeff Davis