Re: Collation versioning
От | Thomas Munro |
---|---|
Тема | Re: Collation versioning |
Дата | |
Msg-id | CAEepm=1xGTsLDx63UEdcJ8MdG63CNJ-tsDWHbH9djtvxRH5ZWw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Collation versioning (Thomas Munro <thomas.munro@enterprisedb.com>) |
Ответы |
Re: Collation versioning
Re: Collation versioning |
Список | pgsql-hackers |
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? -- Thomas Munro http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: