Re: Collation versioning

On 2019-11-04 04:58, Thomas Munro wrote:
> * We'd need to track dependencies on the default collation once we
> have versioning for that (see
> https://www.postgresql.org/message-id/flat/5e756dd6-0e91-d778-96fd-b1bcb06c161a%402ndquadrant.com).
> That is how most people actually consume collations out there in real
> life, and yet we don't normally track dependencies on the default
> collation and I don't know if that's simply a matter of ripping out
> all the code that looks like "xxx != DEFAULT_COLLATION_ID" in the
> dependency analysis code or if there's more to it.

As I was working on that lately, I came to the conclusion that we should 
get *this* patch done first.

My patch for default collation versioning had the version of the default 
collation in the pg_collation record for the "default" collation.  But 
that way you can't set the collation version during CREATE DATABASE. 
It's also pretty complicated (but not impossible) to get the collation 
version in template1 set during initdb.  So you'd need a new mechanism, 
perhaps to store it in pg_database instead.

So instead of going through all those complications of creating this new 
mechanism, only to rip it out again not much later, we should focus on 
moving the per-object tracking forward.  That would solve these problems 
because you don't need to track the version at database creation time, 
only when you create objects using the collations.

> * Some have expressed doubt that pg_depend is the right place for
> this; let's see if any counter-proposals appear.

The only alternative is to create a new catalog that contains exactly 
the same columns as pg_depend (minus deptype) plus the version.  That 
would work but it would just create a lot of code duplication, I think.

One thing I've been thinking about is whether this object-version 
concept could extend to other object types.  For example, if someone 
changes the binary layout of a type, they could change the version of 
the type, and this catalog could track the type version in the column -> 
type dependency.  Obviously, a lot more work would have to be done to 
make this work, but I think the concept of this catalog is sound.

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