Re: Bogus collation version recording in recordMultipleDependencies - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: Bogus collation version recording in recordMultipleDependencies
Date
Msg-id 20210415105647.lqd3kjdic6ixr4dq@nol
Whole thread Raw
In response to Bogus collation version recording in recordMultipleDependencies  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Bogus collation version recording in recordMultipleDependencies  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Apr 14, 2021 at 01:18:07PM -0400, Tom Lane wrote:
> 
> One question here is whether it's correct that the domain's dependency
> on collation "aa_DJ" is unversioned.  Maybe that's intentional, but it
> seems worth asking.

This is intentional I think, we should record collation version only for object
that might break if the collation version is updated.  So creating an index on
that domain would record the collation version.

> Anyway, there are two pretty obvious bugs in the dependencies for the
> domain's CHECK constraint: the version for collation mycoll leaks
> into the entry for function foo, and an entirely useless (because
> unversioned) dependency is recorded on the default collation.

Agreed.

> (To be clear: 0002 passes check-world as-is, while 0001 is not
> committable without some regression-test fiddling.)

I'm probably missing something obvious but both 0001 and 0002 pass check-world
for me, on a glibc box and --with-icu.

> Thoughts?

I think this is an open item, so I added one for now.



pgsql-hackers by date:

Previous
From: Japin Li
Date:
Subject: Forget close an open relation in ReorderBufferProcessTXN()
Next
From: Japin Li
Date:
Subject: Re: Truncate in synchronous logical replication failed