From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)enterprisedb(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-11 21:34:41 |
Message-ID: | 242e081c-aec8-a20a-510c-f4d0f183cebd@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 07/09/2018 23:34, Thomas Munro wrote:
> 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?
This was previously discussed here:
https://www.postgresql.org/message-id/f689322a-4fc5-10cc-4a60-81f1ff0166c9@2ndquadrant.com
-- without a conclusion.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2018-09-11 21:42:07 | Re: Stored procedures and out parameters |
Previous Message | Tom Lane | 2018-09-11 20:37:10 | Re: pg_ugprade test failure on data set with column with default value with type bit/varbit |