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
