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
