-
Notifications
You must be signed in to change notification settings - Fork 214
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide option to specify the charset or collation of text columns in the registry tables #763
Comments
That would remove the need from re-indexing due to collation version mismatch (see https://www.postgresql.org/docs/current/sql-altercollation.html#SQL-ALTERCOLLATION-NOTES) since the C collation does not change. |
Yeah, probably a good idea, although even the C and POSIX collations can change when you upgrade glibc. There was a ton of discussion of the issue at PGCon this year, including this session. Maybe C locale would be the least bad, tho, considering that Sqitch mainly relies on indexes for uniqueness rather than sorting (it mainly sorts by dates). |
I was under the impression that C collation doesn't ever change after reading a comment from @laurenz on a blog article he wrote at https://www.cybertec-postgresql.com/en/icu-collations-against-postgresql-data-corruption/#comment-6208123551
|
Oh, perhaps you're right, I forgot about that. The examples from the presentation use |
Applies also to Yugabyte, and separately add for Cockroach. Using the POSIX collation ensures that index ordering never changes when the database is upgraded, which is a particular problem with glibc collations, but since POSIX/C collation is strictly byte-ordered, it should be fine. Of course, any of use of `ORDER BY` on such columns will return unexpected results when users are used to other locales, but since Sqitch itself only ever orders by timestamp, it should not be an issue in its own use. Closes #763.
Applies to Postgres 9.1 and higher and Yugabyte 2.9 and higher. Using the POSIX collation ensures that index ordering never changes when the database is upgraded, which is a particular problem with glibc collations, but since POSIX/C collation is strictly byte-ordered, it should be fine. Of course, any of use of `ORDER BY` on such columns will return unexpected results when users are used to other locales, but since Sqitch itself only ever orders by timestamp, it should not be an issue in its own use. Closes #763.
Applies to Postgres 9.1 and higher and Yugabyte 2.9 and higher. Using the POSIX collation ensures that index ordering never changes when the database is upgraded, which is a particular problem with glibc collations, but since POSIX/C collation is strictly byte-ordered, it should be fine. Of course, any of use of `ORDER BY` on such columns will return unexpected results when users are used to other locales, but since Sqitch itself only ever orders by timestamp, it should not be an issue in its own use. Closes #763.
Applies to Postgres 9.1 and higher and Yugabyte 2.9 and higher. Using the POSIX collation ensures that index ordering never changes when the database is upgraded, which is a particular problem with glibc collations, but since POSIX/C collation is strictly byte-ordered, it should be fine. Of course, any of use of `ORDER BY` on such columns will return unexpected results when users are used to other locales, but since Sqitch itself only ever orders by timestamp, it should not be an issue in its own use. Closes #763.
Applies to Postgres 9.1 and higher and Yugabyte 2.9 and higher. Using the POSIX collation ensures that index ordering never changes when the database is upgraded, which is a particular problem with glibc collations, but since POSIX/C collation is strictly byte-ordered, it should be fine. Of course, any of use of `ORDER BY` on such columns will return unexpected results when users are used to other locales, but since Sqitch itself only ever orders by timestamp, it should not be an issue in its own use. Closes #763.
Applies to Postgres 9.1 and higher and Yugabyte 2.9 and higher. Using the POSIX collation ensures that index ordering never changes when the database is upgraded, which is a particular problem with glibc collations, but since POSIX/C collation is strictly byte-ordered, it should be fine. Of course, any of use of `ORDER BY` on such columns will return unexpected results when users are used to other locales, but since Sqitch itself only ever orders by timestamp, it should not be an issue in its own use. Closes #763.
Applies to Postgres 9.1 and higher and Yugabyte 2.9 and higher. Using the POSIX collation ensures that index ordering never changes when the database is upgraded, which is a particular problem with glibc collations, but since POSIX/C collation is strictly byte-ordered, it should be fine. Of course, any of use of `ORDER BY` on such columns will return unexpected results when users are used to other locales, but since Sqitch itself only ever orders by timestamp, it should not be an issue in its own use. Closes #763.
Applies to Postgres 9.1 and higher and Yugabyte 2.9 and higher. Using the POSIX collation ensures that index ordering never changes when the database is upgraded, which is a particular problem with glibc collations, but since POSIX/C collation is strictly byte-ordered, it should be fine. Of course, any of use of `ORDER BY` on such columns will return unexpected results when users are used to other locales, but since Sqitch itself only ever orders by timestamp, it should not be an issue in its own use. Closes #763.
Applies to Postgres 9.1 and higher and Yugabyte 2.9 and higher. Using the POSIX collation ensures that index ordering never changes when the database is upgraded, which is a particular problem with glibc collations, but since POSIX/C collation is strictly byte-ordered, it should be fine. Of course, any of use of `ORDER BY` on such columns will return unexpected results when users are used to other locales, but since Sqitch itself only ever orders by timestamp, it should not be an issue in its own use. Closes #763.
Applies to Postgres 9.1 and higher and Yugabyte 2.9 and higher. Using the POSIX collation ensures that index ordering never changes when the database is upgraded, which is a particular problem with glibc collations, but since POSIX/C collation is strictly byte-ordered, it should be fine. Of course, any of use of `ORDER BY` on such columns will return unexpected results when users are used to other locales, but since Sqitch itself only ever orders by timestamp, it should not be an issue in its own use. Closes #763.
I'm gonna drop this issue for now. There just hasn't been the demand, and as my notes in #765 and #857 show, it's a non-trivial problem. If, however, one would like to enforce C/POSIX collation, here's a script to do it: BEGIN;
ALTER TABLE :"registry".releases
ALTER COLUMN installer_name SET DATA TYPE TEXT COLLATE :"collation",
ALTER COLUMN installer_email SET DATA TYPE TEXT COLLATE :"collation"
;
ALTER TABLE :"registry".projects
ALTER COLUMN project SET DATA TYPE TEXT COLLATE :"collation",
ALTER COLUMN uri SET DATA TYPE TEXT COLLATE :"collation",
ALTER COLUMN creator_name SET DATA TYPE TEXT COLLATE :"collation",
ALTER COLUMN creator_email SET DATA TYPE TEXT COLLATE :"collation"
;
ALTER TABLE :"registry".changes
ALTER COLUMN change_id SET DATA TYPE TEXT COLLATE :"collation",
ALTER COLUMN script_hash SET DATA TYPE TEXT COLLATE :"collation",
ALTER COLUMN project SET DATA TYPE TEXT COLLATE :"collation",
ALTER COLUMN note SET DATA TYPE TEXT COLLATE :"collation",
ALTER COLUMN committer_name SET DATA TYPE TEXT COLLATE :"collation",
ALTER COLUMN committer_email SET DATA TYPE TEXT COLLATE :"collation",
ALTER COLUMN planner_name SET DATA TYPE TEXT COLLATE :"collation",
ALTER COLUMN planner_email SET DATA TYPE TEXT COLLATE :"collation"
;
ALTER TABLE :"registry".tags
ALTER COLUMN tag_id SET DATA TYPE TEXT COLLATE :"collation",
ALTER COLUMN tag SET DATA TYPE TEXT COLLATE :"collation",
ALTER COLUMN project SET DATA TYPE TEXT COLLATE :"collation",
ALTER COLUMN change_id SET DATA TYPE TEXT COLLATE :"collation",
ALTER COLUMN note SET DATA TYPE TEXT COLLATE :"collation",
ALTER COLUMN committer_name SET DATA TYPE TEXT COLLATE :"collation",
ALTER COLUMN committer_email SET DATA TYPE TEXT COLLATE :"collation",
ALTER COLUMN planner_name SET DATA TYPE TEXT COLLATE :"collation",
ALTER COLUMN planner_email SET DATA TYPE TEXT COLLATE :"collation"
;
ALTER TABLE :"registry".dependencies
ALTER COLUMN change_id SET DATA TYPE TEXT COLLATE :"collation",
ALTER COLUMN type SET DATA TYPE TEXT COLLATE :"collation",
ALTER COLUMN dependency SET DATA TYPE TEXT COLLATE :"collation",
ALTER COLUMN dependency_id SET DATA TYPE TEXT COLLATE :"collation"
;
ALTER TABLE :"registry".events
ALTER COLUMN change_id SET DATA TYPE TEXT COLLATE :"collation",
ALTER COLUMN change SET DATA TYPE TEXT COLLATE :"collation",
ALTER COLUMN project SET DATA TYPE TEXT COLLATE :"collation",
ALTER COLUMN note SET DATA TYPE TEXT COLLATE :"collation",
ALTER COLUMN requires SET DATA TYPE TEXT[] COLLATE :"collation",
ALTER COLUMN conflicts SET DATA TYPE TEXT[] COLLATE :"collation",
ALTER COLUMN tags SET DATA TYPE TEXT[] COLLATE :"collation",
ALTER COLUMN committer_name SET DATA TYPE TEXT COLLATE :"collation",
ALTER COLUMN committer_email SET DATA TYPE TEXT COLLATE :"collation",
ALTER COLUMN planner_name SET DATA TYPE TEXT COLLATE :"collation",
ALTER COLUMN planner_email SET DATA TYPE TEXT COLLATE :"collation"
;
COMMIT; Use |
PostgreSQL indicates:
Could Sqitch create its tables using the C collation rather than the default collation?
The text was updated successfully, but these errors were encountered: