Re: Collation versioning

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Collation versioning
Дата
Msg-id CA+TgmoajjpPzd9KByrzjfmikgvnhsb9mCQp5=7XReqojcrz9pQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Collation versioning  (Julien Rouhaud <rjuju123@gmail.com>)
Ответы Re: Collation versioning  (Julien Rouhaud <rjuju123@gmail.com>)
Список pgsql-hackers
On Thu, Nov 28, 2019 at 8:08 AM Julien Rouhaud <rjuju123@gmail.com> wrote:
> What we could do is storing an empty string if the compatibility is
> unknown, and detect it in index_check_collation_version() to report a
> slightly different message.  I'm assuming that not knowing the
> compatibility would be system-wide rather than per collation, so we
> could use an sql query like this:
>
> ALTER INDEX idx_name DEPENDS ON COLLATION UNKNOWN VERSION
>
> If adding (un)reserved keywords is not an issue, we could also instead
> use something along ALTER INDEX idx_name DEPENDS ON ALL COLLATIONS
> and/or ALL VERSIONS UNKNOWN, or switch to:

Adding unreserved keywords isn't a huge issue, but it's nicer to avoid
it if we can. Bloating the parser tables isn't that expensive, but
neither is it free. Maybe spell it like this:

ALTER INDEX idx_name DEPENDS ON COLLATION blah VERSION blah;
-- I care about collations and I know which one and which version.

ALTER INDEX idx_name DEPENDS ON SOME COLLATION;
-- I care about collations but I don't know which one.

ALTER INDEX idx_name DEPENDS ON NO COLLATION;
-- I don't care about collations at all.
-- Not sure if we need this.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: Failure in TAP tests of pg_ctl on Windows with parallel instanceset
Следующее
От: Daniel Gustafsson
Дата:
Сообщение: Re: Update minimum SSL version