Re: ICU integration

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: ICU integration
Дата
Msg-id CAEepm=002fm_RiMY0ZjhDnUPOHhWXnk-GrqNAUk7bYQt2dacHA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: ICU integration  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Ответы Re: ICU integration  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Список pgsql-hackers
On Sat, Oct 1, 2016 at 3:30 AM, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
> On 9/23/16 2:27 AM, Thomas Munro wrote:
>> The warning persists even after I reindex all affected tables (and
>> start a new backend), because you're only recording the collation at
>> pg_collation level and then only setting it at initdb time, so that
>> HINT isn't much use for clearing the warning.  I think you'd need to
>> record a snapshot of the version used for each collation that was used
>> on *each index*, and update it whenever you CREATE INDEX or REINDEX
>> etc.  There can of course be more than one collation and thus version
>> involved, if you have columns with different collations, so I guess
>> you'd need an column to hold an array of version snapshots whose order
>> corresponds to pg_index.indcollation's.
>
> Hmm, yeah, that will need more work.  To be completely correct, I think,
> we'd also need to record the version in each expression node, so that
> check constraints of the form CHECK (x > 'abc') can be handled.

Hmm.  That is quite a rabbit hole.  In theory you need to recheck such
a constraint, but it's not at all clear when you should recheck and
what you should do about it if it fails.  Similar for the future
PARTITION feature.

-- 
Thomas Munro
http://www.enterprisedb.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: PoC: Make it possible to disallow WHERE-less UPDATE and DELETE
Следующее
От: Corey Huinker
Дата:
Сообщение: COPY as a set returning function