Re: Collation versioning

On Fri, Dec 6, 2019 at 10:29 AM Julien Rouhaud <rjuju123@gmail.com> wrote:
>
>
> I'm attaching v4 versions, rebased and with the following modifications:
>
> - I implemented the ALTER INDEX name DEPENDS ON [ ANY COLLATION |
> COLLATION name ] [ UNKNOWN VERSION | VERSION blah ] syntax.  Both are
> still only allowed in binary upgrade mode, so I didn't add
> documentation for those, or psql tab completion.
> - Those commands now requires the collation name rather than oid.
> This will be helpful if we want to make the commands above available
> for users, or some similar commands like marking an index depending on
> the current version for some specific collation
> - added the type regcollation to ease pg_dump work
> - unknown collation version is handled with a recorded empty string,
> and lead to a slightly different message
> - new "--collation-binary-compatible" documented option for
> pg_upgrade, leading to using a new and undocumented
> "--unknown-collations-binary-compatible" option for pg_dump.  The new
> option in pg_dump only works in binary upgrade mode, and only prevents
> outputting the ALTER INDEX ... UNKNOWN VERSION commands.  Known
> existing versions are always preserved.
> - dependencies for composite and other exotic types for regular index
> columns should now be correctly handled
> - dependencies for index expression and predicate will now track
> default collation, with additional support for composite types
> - to do so, I had to handle the collation version retrieval in
> recordMultipleDependencies() using a new "track_version" bool
> parameter, passed around in some functions.  This seemed the best way
> to do so, as this is the common point in
> recordDependencyOnSingleRelExpr(), index_create() and others.
>
> The spurious messages when issuing a REINDEX is still not fixed.  I'm
> also attaching an sql file that I used to check all cases of
> non-trivial collation dependencies I could think of.

Hearing no objection in [1], attached v5 with following changes:

- fix the spurious warnings by doing the version check in
get_relation_info and vacuum_open_relation, and add a flag in
RelationData to mark the check as already being done
- change the IsCatalogRelation() check to IsSystemRelation() to also
ignore toast indexes, as those can also be safely ignored too
- add a new ALTER INDEX idxname DEPENDS ON COLLATION collname CURRENT
VERSION to let users remove the warnings for safe library upgrade.
Documentation and tab completion added

If I'm not mistaken, all issues I was aware of are now fixed.

[1] https://www.postgresql.org/message-id/CAOBaU_YbCQ6=8_VOdZY0v-cXX6+BkgScpNRmRjJzESdzv1SZMA@mail.gmail.com