Re: Collation versioning - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Collation versioning
Date
Msg-id CA+hUKGKDN9xROo18gGt=Om4yo610QaPf31iPutaHfqn3xqxu8g@mail.gmail.com
Whole thread Raw
In response to Re: Collation versioning  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
On Thu, Nov 7, 2019 at 1:27 AM Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
> As I was working on that lately, I came to the conclusion that we should
> get *this* patch done first.

Cool.  Let's aim to get this into 13!

> > * 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.

Agreed.

> 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.

Interesting idea.  Sounds like it requires version checks that
actually stop you from using the dependent object, instead of emitting
a few meek warnings.



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Avoiding deadlock errors in CREATE INDEX CONCURRENTLY
Next
From: Michael Paquier
Date:
Subject: Re: Collation versioning