On Fri, Nov 1, 2019 at 2:21 AM Julien Rouhaud <rjuju123@gmail.com> wrote:
> Are you planning to continue working on it? For the record, that's
> something needed to be able to implement a filter in REINDEX command
> [1].
Bonjour Julien,
Unfortunately I haven't had time to work on it seriously, but here's a
quick rebase to get the proof-of-concept back into working shape.
It's nice to see progress in other bits of the problem-space. I hope
to have time to look at this patch set again soon, but if you or
someone else would like hack on or think about it too, please feel
free!
Yes indeed this is exactly the same problem that you're trying to
solve, approached from a different starting point.
Here are some problems to think about:
* We'd need to track dependencies on the default collation once we
have versioning for that (see
https://www.postgresql.org/message-id/flat/5e756dd6-0e91-d778-96fd-b1bcb06c161a%402ndquadrant.com).
That is how most people actually consume collations out there in real
life, and yet we don't normally track dependencies on the default
collation and I don't know if that's simply a matter of ripping out
all the code that looks like "xxx != DEFAULT_COLLATION_ID" in the
dependency analysis code or if there's more to it.
* Andres mentioned off-list that pg_depend rows might get blown away
and recreated in some DDL circumstances. We need to look into that.
* Another is that pg_upgrade won't preserve pg_depend rows, so you'd
need some catalog manipulation (direct or via new DDL) to fix that.
* Some have expressed doubt that pg_depend is the right place for
this; let's see if any counter-proposals appear.
> # reindex table t1;
> WARNING: 01000: index "t1_val_idx" depends on collation 13330 version
> "a153.97.35.8", but the current version is "153.97.35.8"
> DETAIL: The index may be corrupted due to changes in sort order.
> HINT: REINDEX to avoid the risk of corruption.
> LOCATION: index_check_collation_version, index.c:1263
Duh. Yeah, that's stupid and needs to be fixed somehow.
