Re: Collation versioning - Mailing list pgsql-hackers

From Christoph Berg
Subject Re: Collation versioning
Date
Msg-id 20200908193326.GA108231@msg.df7cb.de
Whole thread Raw
In response to Re: Collation versioning  (Julien Rouhaud <rjuju123@gmail.com>)
Responses Re: Collation versioning  (Julien Rouhaud <rjuju123@gmail.com>)
Re: Collation versioning  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
Re: Julien Rouhaud
> Here's the rationale for this new flag, extracted from the patch's commit
> message:
> 
> Add a new amnostablecollorder flag in IndexAmRoutine.
> 
> This flag indicates if the access method does not rely on a stable collation
> ordering for deterministic collation, i.e. would not be corrupted if the
> underlying collation library changes its ordering.  This is done this way to
> make sure that if any external access method isn't updated to correctly setup
> this flag it will be assumed to rely on a stable collation ordering as this
> should be the case for the majority of access methods.
> 
> This flag will be useful for an upcoming commit that will add detection of
> possibly corrupted index due to changed collation library version.

Hmm. Does that flag gain us much? What about non-collation locale
changes that might still affect indexes like lower() and the citext
extension? That still depends on locale changes, but that flag
wouldn't be able to help with "this index is (not) affected by this
locale change".

IOW, I think we should aim at simply tracking the version, and leave
it to the admin (with the help of supplied SQL queries) to either
rebuild indexes or waive them.

Or maybe I misunderstood the problem.

Christoph



pgsql-hackers by date:

Previous
From: David Zhang
Date:
Subject: Re: PATCH: Attempt to make dbsize a bit more consistent
Next
From: Peter Geoghegan
Date:
Subject: Re: Boundary value check in lazy_tid_reaped()