On Tue, Dec 3, 2019 at 9:38 AM Julien Rouhaud <rjuju123@gmail.com> wrote:
>
> On Mon, Dec 2, 2019 at 2:00 PM Robert Haas <robertmhaas@gmail.com> wrote:
> >
> > ALTER INDEX idx_name DEPENDS ON COLLATION blah VERSION blah;
> > -- I care about collations and I know which one and which version.
> >
> > ALTER INDEX idx_name DEPENDS ON SOME COLLATION;
> > -- I care about collations but I don't know which one.
>
> This seems a little bit ambiguous. I wouldn't expect this command to
> trash all recorded versions given how it's spelled.
>
> > ALTER INDEX idx_name DEPENDS ON NO COLLATION;
> > -- I don't care about collations at all.
> > -- Not sure if we need this.
>
> This should be an alias for "trust me all collation are ok"? It's
> certainly useful for collation library upgrade that don't break
> indexes, but I'd prefer to spell it something like "CURRENT VERSION".
> I'll also work on that, but preferably in a later patch as there'll be
> additional need (process all indexes with a given collation or
> collation version for instance).
>
>
> While looking at the list of keywords again, I think that "ANY" is a
> better candidate:
>
> ALTER INDEX idx_name DEPENDS ON [ ANY COLLATION | COLLATION blah ] [
> UNKNOWN VERSION | VERSION blah ]
> or
> ALTER INDEX idx_name ALTER [ ANY COLLATION | COLLATION blah ] DEPENDS
> ON [ UNKNOWN VERSION | VERSION blah ]
>
> I like the 2nd one as it's more obvious that the command will only
> modify existing dependencies.
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.