pgsql: Add a regression test for allow_system_table_mods

Peter Eisentraut <peter@eisentraut.org> writes:

Add a regression test for allow_system_table_mods

Oooh ... some of the buildfarm members are pointing out that this
didn't follow a project convention:

@@ -153,6 +153,7 @@
 ROLLBACK;
 -- reserved tablespace name
 CREATE TABLESPACE pg_foo LOCATION '/no/such/location';
+WARNING:  tablespaces created by regression test cases should have names starting with "regress_"
 ERROR:  directory "/no/such/location" does not exist
 -- triggers
 CREATE TRIGGER t1 BEFORE INSERT ON pg_description EXECUTE FUNCTION tf1();

regards, tom lane

On 2019-11-29 16:27, Tom Lane wrote:

Peter Eisentraut <peter@eisentraut.org> writes:

Add a regression test for allow_system_table_mods

Oooh ... some of the buildfarm members are pointing out that this
didn't follow a project convention:

Um, yes, that's why it's in unsafe_tests. Is there a way around this?

@@ -153,6 +153,7 @@
ROLLBACK;
-- reserved tablespace name
CREATE TABLESPACE pg_foo LOCATION '/no/such/location';
+WARNING:  tablespaces created by regression test cases should have names starting with "regress_"
ERROR:  directory "/no/such/location" does not exist
-- triggers
CREATE TRIGGER t1 BEFORE INSERT ON pg_description EXECUTE FUNCTION tf1();

regards, tom lane

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:

On 2019-11-29 16:27, Tom Lane wrote:

Oooh ... some of the buildfarm members are pointing out that this
didn't follow a project convention:

Um, yes, that's why it's in unsafe_tests. Is there a way around this?

Sure, just change the test tablespace's name to follow the convention:

+WARNING: tablespaces created by regression test cases should have names starting with "regress_"

I agree that this is somewhat pointless in the case of an "unsafe" test.
But using a different name isn't going to invalidate the test case,
so there's not really a reason to not follow the convention. And
trying to have an exception for unsafe_tests seems like a lot more
trouble than it'd be worth.

regards, tom lane

On Fri, Nov 29, 2019 at 11:09:06AM -0500, Tom Lane wrote:

I agree that this is somewhat pointless in the case of an "unsafe" test.
But using a different name isn't going to invalidate the test case,
so there's not really a reason to not follow the convention. And
trying to have an exception for unsafe_tests seems like a lot more
trouble than it'd be worth.

Yeah, I agree that it would be just more simple to make the unsafe
test adopt the convention and be done with it. Could you fix it
please? longfin and mantid (as well as anybody running the unsafe
tests by themselves) are complaining for three days now.
--
Michael

On 2019-11-29 17:09, Tom Lane wrote:

+WARNING: tablespaces created by regression test cases should have names starting with "regress_"

I agree that this is somewhat pointless in the case of an "unsafe" test.
But using a different name isn't going to invalidate the test case,
so there's not really a reason to not follow the convention. And
trying to have an exception for unsafe_tests seems like a lot more
trouble than it'd be worth.

The test case is specifically testing tablespace names starting with "pg_":

-- reserved tablespace name
CREATE TABLESPACE pg_foo LOCATION '/no/such/location';
ERROR: unacceptable tablespace name "pg_foo"
DETAIL: The prefix "pg_" is reserved for system tablespaces.

So using a name starting with "regress_" instead isn't going to help.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:

On 2019-11-29 17:09, Tom Lane wrote:

But using a different name isn't going to invalidate the test case,

The test case is specifically testing tablespace names starting with "pg_":
-- reserved tablespace name
CREATE TABLESPACE pg_foo LOCATION '/no/such/location';
ERROR: unacceptable tablespace name "pg_foo"
DETAIL: The prefix "pg_" is reserved for system tablespaces.

Oh, I see. But is testing that specific error case really worth
the trouble it's going to be to make this pass with or without
-DENFORCE_REGRESSION_TEST_NAME_RESTRICTIONS ?

One way would be to provide a variant expected-file, but that's not going
to be fun for future maintenance of the test script. Another simple
answer is to crank up client_min_messages for this one test to hide the
WARNING, but you could conjure scenarios where that misses something
important. (Of course, not running the test at all would also miss
any such issue.)

regards, tom lane

On Mon, Dec 02, 2019 at 10:11:40AM -0500, Tom Lane wrote:

One way would be to provide a variant expected-file, but that's not going
to be fun for future maintenance of the test script. Another simple
answer is to crank up client_min_messages for this one test to hide the
WARNING, but you could conjure scenarios where that misses something
important. (Of course, not running the test at all would also miss
any such issue.)

Alternate output files should be IMO avoided if we can, so if I were
to choose sneaking a SET client_min_messages would be fine, but only
for the second create tablespace..
--
Michael

On 2019-12-03 05:12, Michael Paquier wrote:

On Mon, Dec 02, 2019 at 10:11:40AM -0500, Tom Lane wrote:

One way would be to provide a variant expected-file, but that's not going
to be fun for future maintenance of the test script. Another simple
answer is to crank up client_min_messages for this one test to hide the
WARNING, but you could conjure scenarios where that misses something
important. (Of course, not running the test at all would also miss
any such issue.)

Alternate output files should be IMO avoided if we can, so if I were
to choose sneaking a SET client_min_messages would be fine, but only
for the second create tablespace..

Fixed that way. I didn't realize it was a warning that could be
silenced that way.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services