From: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | Christoph Berg <myon(at)debian(dot)org>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Collation versioning |
Date: | 2018-09-07 21:34:30 |
Message-ID: | CAEepm=1xGTsLDx63UEdcJ8MdG63CNJ-tsDWHbH9djtvxRH5ZWw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Sep 6, 2018 at 5:36 PM Thomas Munro
<thomas(dot)munro(at)enterprisedb(dot)com> wrote:
> On Thu, Sep 6, 2018 at 12:01 PM Peter Eisentraut
> <peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
> > Also, note that this mechanism only applies to collation objects, not to
> > database-global locales. So most users wouldn't be helped by this approach.
>
> Yeah, right, that would have to work for this to be useful. I will
> look into that.
We could perform a check up front in (say) CheckMyDatabase(), or maybe
defer until the first string comparison. The tricky question is where
to store it.
1. We could add datcollversion to pg_database.
2. We could remove datcollate and datctype and instead store a
collation OID. I'm not sure what problems would come up, but for
starters it seems a bit weird to have a shared catalog pointing to
rows in a non-shared catalog.
The same question comes up if we want to support ICU as a database
level default. Add datcollprovider, or point to a pg_collation row?
--
Thomas Munro
http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-09-07 22:16:28 | Re: buildfarm: could not read block 3 in file "base/16384/2662": read only 0 of 8192 bytes |
Previous Message | Fabien COELHO | 2018-09-07 21:22:14 | Re: libpq stricter integer parsing |