Date: Tue, 18 Sep 2018 21:16:07 -0400
From: Stephen Frost <sfrost@snowman.net>
To: Thomas Munro <thomas.munro@enterprisedb.com>
Cc: Douglas Doole <dougdoole@gmail.com>,
	Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
	Christoph Berg <myon@debian.org>,
	Pg Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Collation versioning
Message-ID: <20180919011607.GU4184@tamriel.snowman.net>
References: 
 <CADE5jYKn6FA0a35P+_HJuSb_abq-D5Z-nE6rO9brjpu8jBTMgA@mail.gmail.com>
 <CAEepm=3-rxTzk3anR1QA=tuNrbAQ_ejJ2rj5Hp_y5hdJQr=rEw@mail.gmail.com>
 <20180916210215.GE4184@tamriel.snowman.net>
 <CAEepm=1wPRi4-YZaSvLXhpzO-6BEyPjBz0qBGpuQ-nmYKAhuvQ@mail.gmail.com>
 <20180918124835.GZ4184@tamriel.snowman.net>
 <CAEepm=1XCyNbhEaU+1tG_dFDVje=q98dg2uQJoJPWMu6HEjW2g@mail.gmail.com>
 <20180918215451.GQ4184@tamriel.snowman.net>
 <CADE5jYL9MRNTRacvCAcPo9bpBo095ReGC1CSYHy-qmuPisX2iw@mail.gmail.com>
 <20180918220931.GS4184@tamriel.snowman.net>
 <CAEepm=3WYE1xqkXk8vV59dzHCZ_qpqk1ptQ9Q0p0YRh-8inK=Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="a7SarfeDDnAelrrD"
Content-Disposition: inline
In-Reply-To: 
 <CAEepm=3WYE1xqkXk8vV59dzHCZ_qpqk1ptQ9Q0p0YRh-8inK=Q@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Precedence: bulk


--a7SarfeDDnAelrrD
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Greetings,

* Thomas Munro (thomas.munro@enterprisedb.com) wrote:
> On Wed, Sep 19, 2018 at 10:09 AM Stephen Frost <sfrost@snowman.net> wrote:
> > * Douglas Doole (dougdoole@gmail.com) wrote:
> > > > The CHECK constraint doesn't need to directly track that informatio=
n-
> > > > it should have a dependency on the column in the table and that's w=
here
> > > > the information would be recorded about the current collation versi=
on.
> > >
> > > Just to have fun throwing odd cases out, how would something like thi=
s 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 COLL=
ATE
> > > "fr_FR"));
> > >
> > > You could even be really warped and apply multiple collations on a si=
ngle
> > > 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..
>=20
> 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 ...

Today, we work out what operators to use for a given column based on the
data type.  This is why I was trying to get at the idea of using typmod
earlier, but if we can't make that work then I'm inclined to try and
figure out a way to get it as close as possible to being associated with
the type.

Yes, the heap is unordered, but the type *is* ordered and we track that
with the type system.  Maybe we just extend that somehow, rather than
using the typmod or adding columns into catalogs where we store type
information (such as pg_attribute).  Perhaps typmod could be made larger
to be able to support this, that might be another approach.

No where in this does it strike me that it makes sense to push this into
pg_depend though.

Thanks!

Stephen

--a7SarfeDDnAelrrD
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJboaNXAAoJEO1sijiDR2RVBrMP/juSplnMK5AkbXB3dd2YQXD+
+3GXbhxZfectbnnP8O0AIPDBvh1wWoCHKeUy7pLdjeuzS1SyF/WYx2JpzpKFfB6w
MPzZQpGk9AxOsliSlZ37yclyJG23VAZbjun7XLTsrukj8xU7MdXfiYD1p0j/oIAy
sLHxI1DJ+jElFVaL4vV+aRwf6/5VrX3+1ppPXYt9GUxK+QuiFpRe+DZt5EzzhDfU
3e5XFub1bputZ7RMHng+sDPWZeUswFmiymsqNCPJ+PZ3m1bmmAhrpDjhPCNIvHJT
cx2uS48CsNFRmFfybcqxMwqO/YxsKvQbh44olFz6JWILLba4rI6d3KMiWem7pFNt
C9hcprHh7SLJj1l9VBKGOh3nB+1hDA50XlvH27BXodqG3gPoI/5oUck+BDmIRkhL
aMJf6gYgBABLsFUDo0mMtadhL3BXyOMIh6RvhuGAPONchAHcWwPJ0PnUZXiA9lvL
j6WjZB4LAmYVEpheeC5UsnthadsGuUi+mr2km8yVYue+SAc7h+AViRgd3+D+HeNq
pxsJcvtlOUP5El/N/uR5oJNq4hf2lzEl6DTUlW7ojg7Z7tPZ4CnnjDyQaYaIBuyM
VFEIC1tJ225awev+q/l7koJ3Aia3SIXS3gMbeQvmuaBZbY8EEegYYUv3rrw5nHDY
RnsAyMumd0H6BR/NMsrZ
=SZlw
-----END PGP SIGNATURE-----

--a7SarfeDDnAelrrD--