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
|
Список | 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 по дате отправления: