Horton

Re: Collation versioning

Peter Eisentraut <peter.eisentraut@2ndquadrant.com>

View thread View on postgr.es
From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
To: Douglas Doole <dougdoole@gmail.com>, Thomas Munro <thomas.munro@enterprisedb.com>
Cc: Christoph Berg <myon@debian.org>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2018-09-27T21:29:52Z
Lists: pgsql-hackers 
On 16/09/2018 20:12, Douglas Doole wrote:
> All this collation stuff is great, and I know users want it, but it
> feels like were pushing them out of an airplane with a ripped parachute
> every time the collation libraries change. Maybe they'll land safely or
> maybe things will get very messy.

At some point, a schema designer also needs to take some responsibility
for making smart choices for longevity.  It is known that collations can
change, and the sort of changes that can happen are also generally
understood.  So if you want to use range partitioning on text fields,
maybe you shouldn't, or at least choose the ranges conservatively.
Similarly, maybe you shouldn't have timestamp range partition boundaries
around DST changes or on the 29th of every month, and maybe you
shouldn't partition float values at negative zero.  Some ideas are
better than others.  We will help you recognize and fix breakage, but we
can't prevent it altogether.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Commits

  1. Doc: Document known problem with Windows collation versions.

  2. Add collation versions for FreeBSD.

  3. Tolerate version lookup failure for old style Windows locale names.

  4. Track collation versions for indexes.

  5. Add pg_depend.refobjversion.

  6. Remove pg_collation.collversion.

  7. Fix the MSVC build for versions 2015 and later.

  8. Add collation versions for Windows.

  9. Implement type regcollation

  10. Use libc version as a collation version on glibc systems.

  11. Make type "name" collation-aware.