Re: Collation versioning
От | Peter Eisentraut |
---|---|
Тема | Re: Collation versioning |
Дата | |
Msg-id | 242e081c-aec8-a20a-510c-f4d0f183cebd@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: Collation versioning (Thomas Munro <thomas.munro@enterprisedb.com>) |
Список | pgsql-hackers |
On 07/09/2018 23:34, Thomas Munro wrote: > On Thu, Sep 6, 2018 at 5:36 PM Thomas Munro > <thomas.munro@enterprisedb.com> wrote: >> On Thu, Sep 6, 2018 at 12:01 PM Peter Eisentraut >> <peter.eisentraut@2ndquadrant.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
В списке pgsql-hackers по дате отправления: