On Wed, Sep 19, 2018 at 10:09 AM Stephen Frost <sfr...@snowman.net> wrote: > * Douglas Doole (dougdo...@gmail.com) wrote: > > > The CHECK constraint doesn't need to directly track that information- > > > it should have a dependency on the column in the table and that's where > > > the information would be recorded about the current collation version. > > > > Just to have fun throwing odd cases out, how would something like this be > > recorded? > > > > Database default collation: en_US > > > > CREATE TABLE t (c1 TEXT, c2 TEXT, c3 TEXT, > > CHECK (c1 COLLATE "fr_FR" BETWEEN c2 COLLATE "fr_FR" AND c3 COLLATE > > "fr_FR")); > > > > You could even be really warped and apply multiple collations on a single > > column in a single constraint. > > Once it gets to an expression and not just a simple check, I'd think > we'd record it in the expression..
Maybe I misunderstood, but I don't think it makes sense to have a collation version "on the column in the table", because (1) that fails to capture the fact that two CHECK constraints that were defined at different times might have become dependent on two different versions (you created one constraint before upgrading and the other after, now the older one is invalidated and sounds the alarm but the second one is fine), and (2) the table itself doesn't care about collation versions since heap tables are unordered; there is no particular operation on the table that would be the correct time to update the collation version on a table/column. What we're trying to track is when objects that in some way depend on the version become invalidated, so wherever we store it there's going to have to be a version recorded per dependent object at its creation time, so that's either new columns on every interested catalog table, or ... -- Thomas Munro http://www.enterprisedb.com
