ALTER COLLATION
ALTER COLLATION — изменить определение правила сортировки
Синтаксис
ALTER COLLATIONимяREFRESH VERSION ALTER COLLATIONимяRENAME TOновое_имяALTER COLLATIONимяOWNER TO {новый_владелец| CURRENT_USER | SESSION_USER } ALTER COLLATIONимяSET SCHEMAновая_схема
Описание
ALTER COLLATION изменяет определение правила сортировки.
Выполнить ALTER COLLATION может только владелец соответствующего правила сортировки. Чтобы сменить владельца, необходимо быть непосредственным или опосредованным членом новой роли-владельца, а эта роль должна иметь право CREATE в схеме правила сортировки. (С такими ограничениями при смене владельца не происходит ничего такого, что нельзя было бы сделать, имея право удалить и вновь создать правило сортировки. Однако суперпользователь может сменить владельца правила сортировки в любом случае.)
Параметры
имяИмя существующего правила сортировки (возможно, дополненное схемой).
новое_имяНовое имя правила сортировки.
новый_владелецНовый владелец правила сортировки.
новая_схемаНовая схема правила сортировки.
REFRESH VERSIONОбновить версию правила сортировки. Подробности в разделе Замечания ниже.
Замечания
Когда применяются правила сортировки, предоставляемые библиотекой ICU, внутренняя версия сортировщика ICU записывается в системный каталог при создании объекта для данного правила. Когда такое правило используется, текущая версия сверяется с записанной и в случае несовпадения выдаётся предупреждение, например такое:
WARNING: collation "xx-x-icu" has version mismatch DETAIL: The collation in the database was created using version 1.2.3.4, but the operating system provides version 2.3.4.5. HINT: Rebuild all objects affected by this collation and run ALTER COLLATION pg_catalog."xx-x-icu" REFRESH VERSION, or build Postgres Pro with the right library version.
Изменения в определениях правил сортировки могут приводить к разрушению индексов и другим проблемам, так как СУБД рассчитывает на то, что хранимые объекты отсортированы в определённом порядке. Вообще этого следует избегать, но это может иметь место в совершенно легальных обстоятельствах, например при обновлении с помощью pg_upgrade исполняемых файлов сервера, скомпонованных с более новой версией ICU. Когда возникает такая ситуация, все объекты, зависящие от данного правила сортировки, должны быть перестроены, например, командой REINDEX. После этой операции можно обновить версию правила сортировки, выполнив команду ALTER COLLATION ... REFRESH VERSION. При этом системный каталог будет обновлён, в него будет записана текущая версия сортировщика, и предупреждение уйдёт. Заметьте, что эта команда собственно не проверяет, были ли все зависимые объекты перестроены корректно.
Когда применяются правила сортировки, предоставляемые библиотекой libc, и PostgreSQL собран с библиотекой GNU C, в качестве версии правила сортировки используется версия библиотеки C. Так как определения правил сортировки обычно меняются только с новыми версиями библиотеки, это даёт некоторую, хотя и не абсолютно надёжную, защиту от искажения данных в базе.
В настоящее время версия правила сортировки, установленного для базы по умолчанию, не отслеживается.
Следующий запрос позволяет выбрать все правила сортировки в текущей базе данных, которые требуют обновления, и зависящие от них объекты:
SELECT pg_describe_object(refclassid, refobjid, refobjsubid) AS "Collation",
pg_describe_object(classid, objid, objsubid) AS "Object"
FROM pg_depend d JOIN pg_collation c
ON refclassid = 'pg_collation'::regclass AND refobjid = c.oid
WHERE c.collversion <> pg_collation_actual_version(c.oid)
ORDER BY 1, 2;
Примеры
Изменение названия правила сортировки с ru_RU на russian:
ALTER COLLATION "ru_RU" RENAME TO russian;
Изменение владельца правила сортировки en_US на joe:
ALTER COLLATION "en_US" OWNER TO joe;
Совместимость
Оператор ALTER COLLATION отсутствует в стандарте SQL.
См. также
CREATE COLLATION, DROP COLLATION18.7. Preventing Server Spoofing
While the server is running, it is not possible for a malicious user to take the place of the normal database server. However, when the server is down, it is possible for a local user to spoof the normal server by starting their own server. The spoof server could read passwords and queries sent by clients, but could not return any data because the PGDATA directory would still be secure because of directory permissions. Spoofing is possible because any user can start a database server; a client cannot identify an invalid server unless it is specially configured.
One way to prevent spoofing of local connections is to use a Unix domain socket directory (unix_socket_directories) that has write permission only for a trusted local user. This prevents a malicious user from creating their own socket file in that directory. If you are concerned that some applications might still reference /tmp for the socket file and hence be vulnerable to spoofing, during operating system startup create a symbolic link /tmp/.s.PGSQL.5432 that points to the relocated socket file. You also might need to modify your /tmp cleanup script to prevent removal of the symbolic link.
Another option for local connections is for clients to use requirepeer to specify the required owner of the server process connected to the socket.
To prevent spoofing on TCP connections, either use SSL certificates and make sure that clients check the server's certificate, or use GSSAPI encryption (or both, if they're on separate connections).
To prevent spoofing with SSL, the server must be configured to accept only hostssl connections (Section 20.1) and have SSL key and certificate files (Section 18.9). The TCP client must connect using sslmode=verify-ca or verify-full and have the appropriate root certificate file installed (Section 36.19.1).
To prevent spoofing with GSSAPI, the server must be configured to accept only hostgssenc connections (Section 20.1) and use gss authentication with them. The TCP client must connect using gssencmode=require.