Add regression tests for COLLATE
Hi,
Please find attached a patch to take 'make check' code-coverage of COLLATE
(/src/backend/commands/collationcmds) from 0% to 96%.
Any feedback is more than welcome. Also posting this to Commitfest-next.
--
Robins Tharakan
Attachments:
regress_collate_v1.patchapplication/octet-stream; name=regress_collate_v1.patchDownload
diff --git a/src/test/regress/expected/collate.out b/src/test/regress/expected/collate.out
index 4ab9566..1b71dd1 100644
--- a/src/test/regress/expected/collate.out
+++ b/src/test/regress/expected/collate.out
@@ -604,6 +604,72 @@ SELECT collation for ((SELECT b FROM collate_test1 LIMIT 1));
"C"
(1 row)
+-- CREATE COLLATE tests
+CREATE COLLATION c2 FROM "C";
+-- Ensure non-OWNER ROLEs are not able to ALTER/DROP COLLATION
+CREATE ROLE role_collate1;
+SET ROLE role_collate1;
+DROP COLLATION c2;
+ERROR: collation "c2" for encoding "UTF8" does not exist
+ALTER COLLATION c2 OWNER TO role_collate1;
+ERROR: collation "c2" for encoding "UTF8" does not exist
+RESET ROLE;
+-- Ensure ALTER COLLATION SET SCHEMA works as expected
+CREATE SCHEMA collate_tests2;
+ALTER COLLATION c2 SET SCHEMA collate_tests2;
+DROP COLLATION collate_tests2.c2;
+DROP SCHEMA collate_tests2;
+-- Should work. Classic cases of CREATE/ALTER COLLATION
+CREATE COLLATION c3 (LOCALE = 'C');
+ALTER COLLATION c3 OWNER TO role_collate1;
+ALTER COLLATION c3 RENAME TO c33;
+DROP COLLATION c33;
+DROP ROLE role_collate1;
+-- Should fail. Give redundant options
+CREATE COLLATION c3a (LOCALE = 'C', LC_COLLATE = 'C', LC_CTYPE= 'C');
+ERROR: conflicting or redundant options
+-- Should fail. LC_COLLATE must be specified
+CREATE COLLATION c5 (LC_CTYPE= 'C');
+ERROR: parameter "lc_collate" must be specified
+-- Should fail. Give value options without value
+CREATE COLLATION c4a (LC_COLLATE = '');
+ERROR: parameter "lc_ctype" must be specified
+CREATE COLLATION c5a (LC_CTYPE= '');
+ERROR: parameter "lc_collate" must be specified
+-- Should fail. Give invalid option name
+CREATE COLLATION c6 (ASDF = 'C');
+ERROR: collation attribute "asdf" not recognized
+-- Ensure error is displayed when a collation already exists
+CREATE COLLATION c7 (LOCALE = 'C');
+CREATE COLLATION c7a (LOCALE = 'C');
+ALTER COLLATION c7a RENAME TO c7;
+ERROR: collation "c7" for encoding "UTF8" already exists in schema "collate_tests"
+DROP COLLATION c7;
+DROP COLLATION c7a;
+-- Ensure error is displayed during ALTER SCHEMA when
+-- the target SCHEMA already contains COLLATION of same name
+CREATE COLLATION c8 (LOCALE = 'C');
+CREATE SCHEMA collate_tests3;
+CREATE COLLATION collate_tests3.c8 (LOCALE = 'C');
+ALTER COLLATION c8 SET SCHEMA collate_tests3;
+ERROR: collation "c8" for encoding "UTF8" already exists in schema "collate_tests3"
+DROP SCHEMA collate_tests3 CASCADE;
+NOTICE: drop cascades to collation c8
+DROP COLLATION c8;
+-- Ensure ROLEs without USAGE access shouldn't be able to CREATE/ALTER COLLATION
+CREATE SCHEMA collate_tests4;
+CREATE COLLATION collate_tests4.c9 (LOCALE = 'C');
+CREATE ROLE role_collate2;
+REVOKE USAGE ON SCHEMA collate_tests4 FROM role_collate2;
+SET ROLE role_collate2;
+ALTER COLLATION collate_tests4.c9 RENAME TO c9b;
+ERROR: permission denied for schema collate_tests4
+CREATE COLLATION collate_tests4.c10 (LOCALE = 'C');
+ERROR: permission denied for schema collate_tests4
+RESET ROLE;
+DROP ROLE role_collate2;
+DROP SCHEMA collate_tests4 CASCADE;
+NOTICE: drop cascades to collation c9
--
-- Clean up. Many of these table names will be re-used if the user is
-- trying to run any platform-specific collation tests later, so we
diff --git a/src/test/regress/sql/collate.sql b/src/test/regress/sql/collate.sql
index 3c960e7..5baf2d2 100644
--- a/src/test/regress/sql/collate.sql
+++ b/src/test/regress/sql/collate.sql
@@ -225,6 +225,69 @@ SELECT collation for ('foo'::text);
SELECT collation for ((SELECT a FROM collate_test1 LIMIT 1)); -- non-collatable type - error
SELECT collation for ((SELECT b FROM collate_test1 LIMIT 1));
+-- CREATE COLLATE tests
+CREATE COLLATION c2 FROM "C";
+
+-- Ensure non-OWNER ROLEs are not able to ALTER/DROP COLLATION
+CREATE ROLE role_collate1;
+SET ROLE role_collate1;
+DROP COLLATION c2;
+ALTER COLLATION c2 OWNER TO role_collate1;
+RESET ROLE;
+
+-- Ensure ALTER COLLATION SET SCHEMA works as expected
+CREATE SCHEMA collate_tests2;
+ALTER COLLATION c2 SET SCHEMA collate_tests2;
+DROP COLLATION collate_tests2.c2;
+DROP SCHEMA collate_tests2;
+
+-- Should work. Classic cases of CREATE/ALTER COLLATION
+CREATE COLLATION c3 (LOCALE = 'C');
+ALTER COLLATION c3 OWNER TO role_collate1;
+ALTER COLLATION c3 RENAME TO c33;
+DROP COLLATION c33;
+DROP ROLE role_collate1;
+
+-- Should fail. Give redundant options
+CREATE COLLATION c3a (LOCALE = 'C', LC_COLLATE = 'C', LC_CTYPE= 'C');
+
+-- Should fail. LC_COLLATE must be specified
+CREATE COLLATION c5 (LC_CTYPE= 'C');
+
+-- Should fail. Give value options without value
+CREATE COLLATION c4a (LC_COLLATE = '');
+CREATE COLLATION c5a (LC_CTYPE= '');
+
+-- Should fail. Give invalid option name
+CREATE COLLATION c6 (ASDF = 'C');
+
+-- Ensure error is displayed when a collation already exists
+CREATE COLLATION c7 (LOCALE = 'C');
+CREATE COLLATION c7a (LOCALE = 'C');
+ALTER COLLATION c7a RENAME TO c7;
+DROP COLLATION c7;
+DROP COLLATION c7a;
+
+-- Ensure error is displayed during ALTER SCHEMA when
+-- the target SCHEMA already contains COLLATION of same name
+CREATE COLLATION c8 (LOCALE = 'C');
+CREATE SCHEMA collate_tests3;
+CREATE COLLATION collate_tests3.c8 (LOCALE = 'C');
+ALTER COLLATION c8 SET SCHEMA collate_tests3;
+DROP SCHEMA collate_tests3 CASCADE;
+DROP COLLATION c8;
+
+-- Ensure ROLEs without USAGE access shouldn't be able to CREATE/ALTER COLLATION
+CREATE SCHEMA collate_tests4;
+CREATE COLLATION collate_tests4.c9 (LOCALE = 'C');
+CREATE ROLE role_collate2;
+REVOKE USAGE ON SCHEMA collate_tests4 FROM role_collate2;
+SET ROLE role_collate2;
+ALTER COLLATION collate_tests4.c9 RENAME TO c9b;
+CREATE COLLATION collate_tests4.c10 (LOCALE = 'C');
+RESET ROLE;
+DROP ROLE role_collate2;
+DROP SCHEMA collate_tests4 CASCADE;
--
-- Clean up. Many of these table names will be re-used if the user is
On Thu, Apr 11, 2013 at 4:14 PM, Robins Tharakan <tharakan@gmail.com> wrote:
Hi,
Please find attached a patch to take 'make check' code-coverage of COLLATE
(/src/backend/commands/collationcmds) from 0% to 96%.Any feedback is more than welcome. Also posting this to Commitfest-next.
Just by having a quick look at the patch, using object names of the type cX
is too generic even if the tests are done in a private schema. Why not
using a name like collate_obj_X or similar?
--
Michael
Hi,
Please find attached the updated patch.
Fabien pointed out that currently does not check for non-trivial locales. I
am still on the learning curve about LOCALEs and so, let me know if this is
a show-stopper. I guess I could look at it and get back in some time with
more tests as Fabien points out.
(Apologies for the delay though. An update to the patch was mostly done
back in April, but since most of the other Code-Coverage patches
(SCHEMA/ROLE/etc.) had no other feedback, I worked on all of them together
just this week).
--
Robins Tharakan
On 12 April 2013 09:28, Michael Paquier <michael.paquier@gmail.com> wrote:
Show quoted text
On Thu, Apr 11, 2013 at 4:14 PM, Robins Tharakan <tharakan@gmail.com>wrote:
Hi,
Please find attached a patch to take 'make check' code-coverage of
COLLATE (/src/backend/commands/collationcmds) from 0% to 96%.Any feedback is more than welcome. Also posting this to Commitfest-next.
Just by having a quick look at the patch, using object names of the type
cX is too generic even if the tests are done in a private schema. Why not
using a name like collate_obj_X or similar?
--
Michael
Attachments:
regress_collate_v2.patchapplication/octet-stream; name=regress_collate_v2.patchDownload
diff --git a/src/test/regress/expected/collate.out b/src/test/regress/expected/collate.out
index 4ab9566..729ea2e 100644
--- a/src/test/regress/expected/collate.out
+++ b/src/test/regress/expected/collate.out
@@ -604,6 +604,72 @@ SELECT collation for ((SELECT b FROM collate_test1 LIMIT 1));
"C"
(1 row)
+-- CREATE COLLATE tests
+CREATE COLLATION collate_coll2 FROM "C";
+-- Ensure non-OWNER ROLEs are not able to ALTER/DROP COLLATION
+CREATE ROLE role_collate1;
+SET ROLE role_collate1;
+DROP COLLATION collate_coll2;
+ERROR: collation "collate_coll2" for encoding "UTF8" does not exist
+ALTER COLLATION collate_coll2 OWNER TO role_collate1;
+ERROR: collation "collate_coll2" for encoding "UTF8" does not exist
+RESET ROLE;
+-- Ensure ALTER COLLATION SET SCHEMA works as expected
+CREATE SCHEMA collate_tests2;
+ALTER COLLATION collate_coll2 SET SCHEMA collate_tests2;
+DROP COLLATION collate_tests2.collate_coll2;
+DROP SCHEMA collate_tests2;
+-- Should work. Classic cases of CREATE/ALTER COLLATION
+CREATE COLLATION collate_coll3 (LOCALE = 'C');
+ALTER COLLATION collate_coll3 OWNER TO role_collate1;
+ALTER COLLATION collate_coll3 RENAME TO collate_coll33;
+DROP COLLATION collate_coll33;
+DROP ROLE role_collate1;
+-- Should fail. Give redundant options
+CREATE COLLATION collate_coll3a (LOCALE = 'C', LC_COLLATE = 'C', LC_CTYPE= 'C');
+ERROR: conflicting or redundant options
+-- Should fail. LC_COLLATE must be specified
+CREATE COLLATION collate_coll5 (LC_CTYPE= 'C');
+ERROR: parameter "lc_collate" must be specified
+-- Should fail. Give value options without value
+CREATE COLLATION collate_coll4a (LC_COLLATE = '');
+ERROR: parameter "lc_ctype" must be specified
+CREATE COLLATION collate_coll5a (LC_CTYPE= '');
+ERROR: parameter "lc_collate" must be specified
+-- Should fail. Give invalid option name
+CREATE COLLATION collate_coll6 (ASDF = 'C');
+ERROR: collation attribute "asdf" not recognized
+-- Ensure error is displayed when a collation already exists
+CREATE COLLATION collate_coll7 (LOCALE = 'C');
+CREATE COLLATION collate_coll7a (LOCALE = 'C');
+ALTER COLLATION collate_coll7a RENAME TO collate_coll7;
+ERROR: collation "collate_coll7" for encoding "UTF8" already exists in schema "collate_tests"
+DROP COLLATION collate_coll7;
+DROP COLLATION collate_coll7a;
+-- Ensure error is displayed during ALTER SCHEMA when
+-- the target SCHEMA already contains COLLATION of same name
+CREATE COLLATION collate_coll8 (LOCALE = 'C');
+CREATE SCHEMA collate_tests3;
+CREATE COLLATION collate_tests3.collate_coll8 (LOCALE = 'C');
+ALTER COLLATION collate_coll8 SET SCHEMA collate_tests3;
+ERROR: collation "collate_coll8" for encoding "UTF8" already exists in schema "collate_tests3"
+DROP SCHEMA collate_tests3 CASCADE;
+NOTICE: drop cascades to collation collate_coll8
+DROP COLLATION collate_coll8;
+-- Ensure ROLEs without USAGE access shouldn't be able to CREATE/ALTER COLLATION
+CREATE SCHEMA collate_tests4;
+CREATE COLLATION collate_tests4.collate_coll9 (LOCALE = 'C');
+CREATE ROLE role_collate2;
+REVOKE USAGE ON SCHEMA collate_tests4 FROM role_collate2;
+SET ROLE role_collate2;
+ALTER COLLATION collate_tests4.collate_coll9 RENAME TO collate_coll9b;
+ERROR: permission denied for schema collate_tests4
+CREATE COLLATION collate_tests4.collate_coll10 (LOCALE = 'C');
+ERROR: permission denied for schema collate_tests4
+RESET ROLE;
+DROP ROLE role_collate2;
+DROP SCHEMA collate_tests4 CASCADE;
+NOTICE: drop cascades to collation collate_coll9
--
-- Clean up. Many of these table names will be re-used if the user is
-- trying to run any platform-specific collation tests later, so we
diff --git a/src/test/regress/sql/collate.sql b/src/test/regress/sql/collate.sql
index 3c960e7..db84842 100644
--- a/src/test/regress/sql/collate.sql
+++ b/src/test/regress/sql/collate.sql
@@ -225,6 +225,69 @@ SELECT collation for ('foo'::text);
SELECT collation for ((SELECT a FROM collate_test1 LIMIT 1)); -- non-collatable type - error
SELECT collation for ((SELECT b FROM collate_test1 LIMIT 1));
+-- CREATE COLLATE tests
+CREATE COLLATION collate_coll2 FROM "C";
+
+-- Ensure non-OWNER ROLEs are not able to ALTER/DROP COLLATION
+CREATE ROLE role_collate1;
+SET ROLE role_collate1;
+DROP COLLATION collate_coll2;
+ALTER COLLATION collate_coll2 OWNER TO role_collate1;
+RESET ROLE;
+
+-- Ensure ALTER COLLATION SET SCHEMA works as expected
+CREATE SCHEMA collate_tests2;
+ALTER COLLATION collate_coll2 SET SCHEMA collate_tests2;
+DROP COLLATION collate_tests2.collate_coll2;
+DROP SCHEMA collate_tests2;
+
+-- Should work. Classic cases of CREATE/ALTER COLLATION
+CREATE COLLATION collate_coll3 (LOCALE = 'C');
+ALTER COLLATION collate_coll3 OWNER TO role_collate1;
+ALTER COLLATION collate_coll3 RENAME TO collate_coll33;
+DROP COLLATION collate_coll33;
+DROP ROLE role_collate1;
+
+-- Should fail. Give redundant options
+CREATE COLLATION collate_coll3a (LOCALE = 'C', LC_COLLATE = 'C', LC_CTYPE= 'C');
+
+-- Should fail. LC_COLLATE must be specified
+CREATE COLLATION collate_coll5 (LC_CTYPE= 'C');
+
+-- Should fail. Give value options without value
+CREATE COLLATION collate_coll4a (LC_COLLATE = '');
+CREATE COLLATION collate_coll5a (LC_CTYPE= '');
+
+-- Should fail. Give invalid option name
+CREATE COLLATION collate_coll6 (ASDF = 'C');
+
+-- Ensure error is displayed when a collation already exists
+CREATE COLLATION collate_coll7 (LOCALE = 'C');
+CREATE COLLATION collate_coll7a (LOCALE = 'C');
+ALTER COLLATION collate_coll7a RENAME TO collate_coll7;
+DROP COLLATION collate_coll7;
+DROP COLLATION collate_coll7a;
+
+-- Ensure error is displayed during ALTER SCHEMA when
+-- the target SCHEMA already contains COLLATION of same name
+CREATE COLLATION collate_coll8 (LOCALE = 'C');
+CREATE SCHEMA collate_tests3;
+CREATE COLLATION collate_tests3.collate_coll8 (LOCALE = 'C');
+ALTER COLLATION collate_coll8 SET SCHEMA collate_tests3;
+DROP SCHEMA collate_tests3 CASCADE;
+DROP COLLATION collate_coll8;
+
+-- Ensure ROLEs without USAGE access shouldn't be able to CREATE/ALTER COLLATION
+CREATE SCHEMA collate_tests4;
+CREATE COLLATION collate_tests4.collate_coll9 (LOCALE = 'C');
+CREATE ROLE role_collate2;
+REVOKE USAGE ON SCHEMA collate_tests4 FROM role_collate2;
+SET ROLE role_collate2;
+ALTER COLLATION collate_tests4.collate_coll9 RENAME TO collate_coll9b;
+CREATE COLLATION collate_tests4.collate_coll10 (LOCALE = 'C');
+RESET ROLE;
+DROP ROLE role_collate2;
+DROP SCHEMA collate_tests4 CASCADE;
--
-- Clean up. Many of these table names will be re-used if the user is
Robins Tharakan <tharakan@gmail.com> writes:
Fabien pointed out that currently does not check for non-trivial locales. I
am still on the learning curve about LOCALEs and so, let me know if this is
a show-stopper. I guess I could look at it and get back in some time with
more tests as Fabien points out.
You really can't, because there is no guarantee that any given machine
will have anything except "C" and "POSIX". But there's another problem:
I believe this test will fail on any machine where the database is
created with an encoding different from UTF8, because that encoding is
named in some of the error messages in the expected output.
This stuff is not easy to test in a portable way.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Fabien pointed out that currently does not check for non-trivial locales.
Indeed, but although it was not very from my point (my wish), and as
pointed out by Tom, it is not quite possible to test non trivial locales
because you cannot assume that a given locale is available on any test
machine.
Maybe some tests could be applied under some condition, say a given locale
is indeed available, but ISTM that it would require to change the test
infrastructure in a portable way to add such feature.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Maybe some tests could be applied under some condition, say a given locale is
indeed available, but ISTM that it would require to change the test
infrastructure in a portable way to add such feature.
I just noticed that there is a "src/test/locale" directory with some stuff
about german, greek and korean, so ISTM that the infrastructure is there,
and could be populated with other locales, especially something with UTF8
which is quite commonplace, would be nice.
However, it is not clear whether these tests run automatically or only if
they are explicitely called. The README seems to suggest that it is the
later. If so, maybe having them invoked automatically if possible would
ensure that they are run from time to time.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, May 9, 2013 at 4:19 PM, Fabien COELHO <coelho@cri.ensmp.fr> wrote:
However, it is not clear whether these tests run automatically or only if
they are explicitely called. The README seems to suggest that it is the
later. If so, maybe having them invoked automatically if possible would
ensure that they are run from time to time.
Only isolation and regress are run automatically inside the buildfarm.
--
Michael
One workaround is to use DROP COLLATION IF EXISTS, that conveys the message
without UTF8 in the message string.
But three other tests use ALTER COLLATION and I see no way but to comment /
disable them. Currently have them disabled (with comments as to what they
do, and why they're disabled).
This updated patch doesn't have UTF8 string anywhere.
Let me know if you prefer to remove the commented out tests completely.
--
Robins Tharakan
On 9 May 2013 07:44, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Show quoted text
Robins Tharakan <tharakan@gmail.com> writes:
Fabien pointed out that currently does not check for non-trivial
locales. I
am still on the learning curve about LOCALEs and so, let me know if this
is
a show-stopper. I guess I could look at it and get back in some time with
more tests as Fabien points out.You really can't, because there is no guarantee that any given machine
will have anything except "C" and "POSIX". But there's another problem:
I believe this test will fail on any machine where the database is
created with an encoding different from UTF8, because that encoding is
named in some of the error messages in the expected output.This stuff is not easy to test in a portable way.
regards, tom lane
Attachments:
regress_collate_v3.patchapplication/octet-stream; name=regress_collate_v3.patchDownload
diff --git a/src/test/regress/expected/collate.out b/src/test/regress/expected/collate.out
index 91d574d..e92626b 100644
--- a/src/test/regress/expected/collate.out
+++ b/src/test/regress/expected/collate.out
@@ -626,6 +626,74 @@ SELECT collation for ((SELECT b FROM collate_test1 LIMIT 1));
"C"
(1 row)
+-- CREATE COLLATE tests
+CREATE COLLATION collate_coll2 FROM "C";
+-- Ensure non-OWNER ROLEs are not able to ALTER/DROP COLLATION
+CREATE ROLE role_collate1;
+SET ROLE role_collate1;
+DROP COLLATION IF EXISTS collate_coll2;
+NOTICE: collation "collate_coll2" does not exist, skipping
+-- Currently no way to test this without ensuring that this test works on
+-- all kinds of systems (even without UTF8 encoding DBs)
+-- ALTER COLLATION collate_coll2 OWNER TO role_collate1;
+RESET ROLE;
+-- Ensure ALTER COLLATION SET SCHEMA works as expected
+CREATE SCHEMA collate_tests2;
+ALTER COLLATION collate_coll2 SET SCHEMA collate_tests2;
+DROP COLLATION collate_tests2.collate_coll2;
+DROP SCHEMA collate_tests2;
+-- Should work. Classic cases of CREATE/ALTER COLLATION
+CREATE COLLATION collate_coll3 (LOCALE = 'C');
+ALTER COLLATION collate_coll3 OWNER TO role_collate1;
+ALTER COLLATION collate_coll3 RENAME TO collate_coll33;
+DROP COLLATION collate_coll33;
+DROP ROLE role_collate1;
+-- Should fail. Give redundant options
+CREATE COLLATION collate_coll3a (LOCALE = 'C', LC_COLLATE = 'C', LC_CTYPE= 'C');
+ERROR: conflicting or redundant options
+-- Should fail. LC_COLLATE must be specified
+CREATE COLLATION collate_coll5 (LC_CTYPE= 'C');
+ERROR: parameter "lc_collate" must be specified
+-- Should fail. Give value options without value
+CREATE COLLATION collate_coll4a (LC_COLLATE = '');
+ERROR: parameter "lc_ctype" must be specified
+CREATE COLLATION collate_coll5a (LC_CTYPE= '');
+ERROR: parameter "lc_collate" must be specified
+-- Should fail. Give invalid option name
+CREATE COLLATION collate_coll6 (ASDF = 'C');
+ERROR: collation attribute "asdf" not recognized
+-- Ensure error is displayed when a collation is RENAMEd but that named collation already exists
+-- Currently no way to test this without ensuring that this test works on
+-- all kinds of systems (even without UTF8 encoding DBs)
+-- CREATE COLLATION collate_coll7 (LOCALE = 'C');
+-- CREATE COLLATION collate_coll7a (LOCALE = 'C');
+-- ALTER COLLATION collate_coll7a RENAME TO collate_coll7;
+-- DROP COLLATION collate_coll7;
+-- DROP COLLATION collate_coll7a;
+-- Ensure error is displayed during ALTER COLLATION SET SCHEMA when
+-- the target SCHEMA already contains COLLATION of same name
+-- Currently no way to test this without ensuring that this test works on
+-- all kinds of systems (even without UTF8 encoding DBs)
+-- CREATE COLLATION collate_coll8 (LOCALE = 'C');
+-- CREATE SCHEMA collate_tests3;
+-- CREATE COLLATION collate_tests3.collate_coll8 (LOCALE = 'C');
+-- ALTER COLLATION collate_coll8 SET SCHEMA collate_tests3;
+-- DROP SCHEMA collate_tests3 CASCADE;
+-- DROP COLLATION collate_coll8;
+-- Ensure ROLEs without USAGE access shouldn't be able to CREATE/ALTER COLLATION
+CREATE SCHEMA collate_tests4;
+CREATE COLLATION collate_tests4.collate_coll9 (LOCALE = 'C');
+CREATE ROLE role_collate2;
+REVOKE USAGE ON SCHEMA collate_tests4 FROM role_collate2;
+SET ROLE role_collate2;
+ALTER COLLATION collate_tests4.collate_coll9 RENAME TO collate_coll9b;
+ERROR: permission denied for schema collate_tests4
+CREATE COLLATION collate_tests4.collate_coll10 (LOCALE = 'C');
+ERROR: permission denied for schema collate_tests4
+RESET ROLE;
+DROP ROLE role_collate2;
+DROP SCHEMA collate_tests4 CASCADE;
+NOTICE: drop cascades to collation collate_coll9
--
-- Clean up. Many of these table names will be re-used if the user is
-- trying to run any platform-specific collation tests later, so we
diff --git a/src/test/regress/parallel_schedule b/src/test/regress/parallel_schedule
index 2af28b1..7360f8b 100644
--- a/src/test/regress/parallel_schedule
+++ b/src/test/regress/parallel_schedule
@@ -59,7 +59,7 @@ test: create_index create_view
# ----------
# Another group of parallel tests
# ----------
-test: create_aggregate create_function_3 create_cast constraints triggers inherit create_table_like typed_table vacuum drop_if_exists updatable_views
+test: create_aggregate create_function_3 create_cast constraints triggers inherit create_table_like typed_table vacuum drop_if_exists updatable_views user
# ----------
# sanity_check does a vacuum, affecting the sort order of SELECT *
diff --git a/src/test/regress/sql/collate.sql b/src/test/regress/sql/collate.sql
index 63ab590..0f47477 100644
--- a/src/test/regress/sql/collate.sql
+++ b/src/test/regress/sql/collate.sql
@@ -231,6 +231,75 @@ SELECT collation for ('foo'::text);
SELECT collation for ((SELECT a FROM collate_test1 LIMIT 1)); -- non-collatable type - error
SELECT collation for ((SELECT b FROM collate_test1 LIMIT 1));
+-- CREATE COLLATE tests
+CREATE COLLATION collate_coll2 FROM "C";
+
+-- Ensure non-OWNER ROLEs are not able to ALTER/DROP COLLATION
+CREATE ROLE role_collate1;
+SET ROLE role_collate1;
+DROP COLLATION IF EXISTS collate_coll2;
+-- Currently no way to test this without ensuring that this test works on
+-- all kinds of systems (even without UTF8 encoding DBs)
+-- ALTER COLLATION collate_coll2 OWNER TO role_collate1;
+RESET ROLE;
+
+-- Ensure ALTER COLLATION SET SCHEMA works as expected
+CREATE SCHEMA collate_tests2;
+ALTER COLLATION collate_coll2 SET SCHEMA collate_tests2;
+DROP COLLATION collate_tests2.collate_coll2;
+DROP SCHEMA collate_tests2;
+
+-- Should work. Classic cases of CREATE/ALTER COLLATION
+CREATE COLLATION collate_coll3 (LOCALE = 'C');
+ALTER COLLATION collate_coll3 OWNER TO role_collate1;
+ALTER COLLATION collate_coll3 RENAME TO collate_coll33;
+DROP COLLATION collate_coll33;
+DROP ROLE role_collate1;
+
+-- Should fail. Give redundant options
+CREATE COLLATION collate_coll3a (LOCALE = 'C', LC_COLLATE = 'C', LC_CTYPE= 'C');
+
+-- Should fail. LC_COLLATE must be specified
+CREATE COLLATION collate_coll5 (LC_CTYPE= 'C');
+
+-- Should fail. Give value options without value
+CREATE COLLATION collate_coll4a (LC_COLLATE = '');
+CREATE COLLATION collate_coll5a (LC_CTYPE= '');
+
+-- Should fail. Give invalid option name
+CREATE COLLATION collate_coll6 (ASDF = 'C');
+
+-- Ensure error is displayed when a collation is RENAMEd but that named collation already exists
+-- Currently no way to test this without ensuring that this test works on
+-- all kinds of systems (even without UTF8 encoding DBs)
+-- CREATE COLLATION collate_coll7 (LOCALE = 'C');
+-- CREATE COLLATION collate_coll7a (LOCALE = 'C');
+-- ALTER COLLATION collate_coll7a RENAME TO collate_coll7;
+-- DROP COLLATION collate_coll7;
+-- DROP COLLATION collate_coll7a;
+
+-- Ensure error is displayed during ALTER COLLATION SET SCHEMA when
+-- the target SCHEMA already contains COLLATION of same name
+-- Currently no way to test this without ensuring that this test works on
+-- all kinds of systems (even without UTF8 encoding DBs)
+-- CREATE COLLATION collate_coll8 (LOCALE = 'C');
+-- CREATE SCHEMA collate_tests3;
+-- CREATE COLLATION collate_tests3.collate_coll8 (LOCALE = 'C');
+-- ALTER COLLATION collate_coll8 SET SCHEMA collate_tests3;
+-- DROP SCHEMA collate_tests3 CASCADE;
+-- DROP COLLATION collate_coll8;
+
+-- Ensure ROLEs without USAGE access shouldn't be able to CREATE/ALTER COLLATION
+CREATE SCHEMA collate_tests4;
+CREATE COLLATION collate_tests4.collate_coll9 (LOCALE = 'C');
+CREATE ROLE role_collate2;
+REVOKE USAGE ON SCHEMA collate_tests4 FROM role_collate2;
+SET ROLE role_collate2;
+ALTER COLLATION collate_tests4.collate_coll9 RENAME TO collate_coll9b;
+CREATE COLLATION collate_tests4.collate_coll10 (LOCALE = 'C');
+RESET ROLE;
+DROP ROLE role_collate2;
+DROP SCHEMA collate_tests4 CASCADE;
--
-- Clean up. Many of these table names will be re-used if the user is
On Thu, May 9, 2013 at 9:27 PM, Robins Tharakan <tharakan@gmail.com> wrote:
One workaround is to use DROP COLLATION IF EXISTS, that conveys the message
without UTF8 in the message string.But three other tests use ALTER COLLATION and I see no way but to comment /
disable them. Currently have them disabled (with comments as to what they
do, and why they're disabled).This updated patch doesn't have UTF8 string anywhere.
Let me know if you prefer to remove the commented out tests completely.
I did remove those, plus made some other cleanups, and committed this.
I think that there's now some duplication between this and the
collate.linux.utf8 test that should be cleaned up by removing the
duplicative stuff from that test, assuming this holds up OK when the
buildfarm - and other developers - test it out. Could you prepare a
patch towards that end?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
I did remove those, plus made some other cleanups, and committed this.
I think that there's now some duplication between this and the
collate.linux.utf8 test that should be cleaned up by removing the
duplicative stuff from that test, assuming this holds up OK when the
buildfarm - and other developers - test it out.
I don't even need to test it:
regression=# CREATE COLLATION collate_coll2 FROM "C";
ERROR: nondefault collations are not supported on this platform
Please revert.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Jul 3, 2013 at 1:11 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Robert Haas <robertmhaas@gmail.com> writes:
I did remove those, plus made some other cleanups, and committed this.
I think that there's now some duplication between this and the
collate.linux.utf8 test that should be cleaned up by removing the
duplicative stuff from that test, assuming this holds up OK when the
buildfarm - and other developers - test it out.I don't even need to test it:
regression=# CREATE COLLATION collate_coll2 FROM "C";
ERROR: nondefault collations are not supported on this platformPlease revert.
OK, sure, but just for my education and general enlightenment ... what
platform is that?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Jul 3, 2013 at 1:26 PM, Robert Haas <robertmhaas@gmail.com> wrote:
Please revert.
OK, sure, but just for my education and general enlightenment ... what
platform is that?
Ah, never mind. I see that the buildfarm is quickly turning red -
NetBSD, OmniOS, and HP/UX are all unhappy.
I think that's a killer blow for this particular patch. I'm going to
set this to rejected in the CF app.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2013-07-03 13:29:18 -0400, Robert Haas wrote:
On Wed, Jul 3, 2013 at 1:26 PM, Robert Haas <robertmhaas@gmail.com> wrote:
Please revert.
OK, sure, but just for my education and general enlightenment ... what
platform is that?Ah, never mind. I see that the buildfarm is quickly turning red -
NetBSD, OmniOS, and HP/UX are all unhappy.I think that's a killer blow for this particular patch. I'm going to
set this to rejected in the CF app.
Can't we use a alternative expected file for those?
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Andres Freund <andres@2ndquadrant.com> writes:
On 2013-07-03 13:29:18 -0400, Robert Haas wrote:
I think that's a killer blow for this particular patch. I'm going to
set this to rejected in the CF app.
Can't we use a alternative expected file for those?
Alternative expected files are a PITA to maintain, at least for
committers who don't have a platform that can reproduce the alternative
behavior. If this test were of somewhat higher value I'd be in favor of
fixing it that way, but given that it's been seriously constrained by
the portability issues that were already considered, I'm not sure it's
worth our trouble. (There's also no very strong reason to believe that
we found out all the remaining portability issues. Maybe we should have
left it in there for a day, just to see if the buildfarm would show any
other symptoms besides this one.)
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Jul 3, 2013 at 1:38 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Andres Freund <andres@2ndquadrant.com> writes:
On 2013-07-03 13:29:18 -0400, Robert Haas wrote:
I think that's a killer blow for this particular patch. I'm going to
set this to rejected in the CF app.Can't we use a alternative expected file for those?
Alternative expected files are a PITA to maintain, at least for
committers who don't have a platform that can reproduce the alternative
behavior. If this test were of somewhat higher value I'd be in favor of
fixing it that way, but given that it's been seriously constrained by
the portability issues that were already considered, I'm not sure it's
worth our trouble. (There's also no very strong reason to believe that
we found out all the remaining portability issues. Maybe we should have
left it in there for a day, just to see if the buildfarm would show any
other symptoms besides this one.)
I agree. I think it'd be a good idea to get the buildfarm to run the
existing collate.utf8.linux test regularly on platforms where it
passes, but this particular approach is valuable mostly because
(supposedly) it was going to work everywhere. However, it doesn't.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas escribi�:
I agree. I think it'd be a good idea to get the buildfarm to run the
existing collate.utf8.linux test regularly on platforms where it
passes,
+1
--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 07/03/2013 03:00 PM, Alvaro Herrera wrote:
Robert Haas escribió:
I agree. I think it'd be a good idea to get the buildfarm to run the
existing collate.utf8.linux test regularly on platforms where it
passes,+1
I can probably whip up a module for it. (I created the buildfarm module
system so people could create their own addons, but sadly nobody seems
to have risen to the bait.)
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 07/03/2013 03:16 PM, Andrew Dunstan wrote:
On 07/03/2013 03:00 PM, Alvaro Herrera wrote:
Robert Haas escribió:
I agree. I think it'd be a good idea to get the buildfarm to run the
existing collate.utf8.linux test regularly on platforms where it
passes,+1
I can probably whip up a module for it. (I created the buildfarm
module system so people could create their own addons, but sadly
nobody seems to have risen to the bait.)
I have added it to crake's set of modules to run, See
<http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=crake&dt=2013-07-05%2023%3A26%3A17&stg=FileTextArrayFDW-installcheck-en_US.utf8>,
and it will be in the next buildfarm client release.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 07/05/2013 07:44 PM, Andrew Dunstan wrote:
On 07/03/2013 03:16 PM, Andrew Dunstan wrote:
On 07/03/2013 03:00 PM, Alvaro Herrera wrote:
Robert Haas escribió:
I agree. I think it'd be a good idea to get the buildfarm to run the
existing collate.utf8.linux test regularly on platforms where it
passes,+1
I can probably whip up a module for it. (I created the buildfarm
module system so people could create their own addons, but sadly
nobody seems to have risen to the bait.)I have added it to crake's set of modules to run, See
<http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=crake&dt=2013-07-05%2023%3A26%3A17&stg=FileTextArrayFDW-installcheck-en_US.utf8>,
and it will be in the next buildfarm client release.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2013-07-03 14:17:20 -0400, Robert Haas wrote:
I agree. I think it'd be a good idea to get the buildfarm to run the
existing collate.utf8.linux test regularly on platforms where it
passes, but this particular approach is valuable mostly because
(supposedly) it was going to work everywhere. However, it doesn't.
Hm. What about extending the existing resultmap logic to make that
possible in general? E.g. don't run the test if a file is mapped to an
empty expected file.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Jul 5, 2013 at 6:56 PM, Andres Freund <andres@2ndquadrant.com> wrote:
On 2013-07-03 14:17:20 -0400, Robert Haas wrote:
I agree. I think it'd be a good idea to get the buildfarm to run the
existing collate.utf8.linux test regularly on platforms where it
passes, but this particular approach is valuable mostly because
(supposedly) it was going to work everywhere. However, it doesn't.Hm. What about extending the existing resultmap logic to make that
possible in general? E.g. don't run the test if a file is mapped to an
empty expected file.
Not a bad thought.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 07/06/2013 09:12 AM, Robert Haas wrote:
On Fri, Jul 5, 2013 at 6:56 PM, Andres Freund <andres@2ndquadrant.com> wrote:
On 2013-07-03 14:17:20 -0400, Robert Haas wrote:
I agree. I think it'd be a good idea to get the buildfarm to run the
existing collate.utf8.linux test regularly on platforms where it
passes, but this particular approach is valuable mostly because
(supposedly) it was going to work everywhere. However, it doesn't.Hm. What about extending the existing resultmap logic to make that
possible in general? E.g. don't run the test if a file is mapped to an
empty expected file.Not a bad thought.
Or maybe just invent a magic result file name such as "none" or
"do_not_run".
I'm not keen to have us build up a large patchwork of regression tests
that run on some platforms and not on others, though.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sat, Jul 6, 2013 at 9:27 AM, Andrew Dunstan <andrew@dunslane.net> wrote:
Or maybe just invent a magic result file name such as "none" or
"do_not_run".I'm not keen to have us build up a large patchwork of regression tests that
run on some platforms and not on others, though.
Me, neither. But I don't really see a plausible alternative in this
particular case, since we're trying to test a feature that only works
in the presence of specific platform support. I don't think that
having no buildfarm testing of collation support is better.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers