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  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Re: Collation versioning  (Christoph Berg <myon@debian.org>)
Список 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 по дате отправления:

Предыдущее
От: Fabien COELHO
Дата:
Сообщение: Re: libpq stricter integer parsing
Следующее
От: Tom Lane
Дата:
Сообщение: Re: buildfarm: could not read block 3 in file "base/16384/2662": read only 0 of 8192 bytes