pgsql: Add a regression test for allow_system_table_mods

Add a regression test for allow_system_table_mods

Add a regression test file that exercises the kinds of commands that
allow_system_table_mods allows.

This is put in the "unsafe_tests" suite, so it won't accidentally
create a mess if someone runs the normal regression tests against an
instance that they care about.

Reviewed-by: Tom Lane <[hidden email]>
Discussion: https://www.postgresql.org/message-id/flat/8b00ea5e-28a7-88ba-e848-21528b632354%402ndquadrant.com

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/7fc380f83d466b43a8f65bb52c925c1ab19736ea

Modified Files
--------------
src/test/modules/unsafe_tests/Makefile             |   2 +-
.../unsafe_tests/expected/alter_system_table.out   | 168 +++++++++++++++++++
.../unsafe_tests/sql/alter_system_table.sql        | 185 +++++++++++++++++++++
src/test/regress/expected/alter_table.out          |   4 -
src/test/regress/sql/alter_table.sql               |   4 -
5 files changed, 354 insertions(+), 9 deletions(-)

Peter Eisentraut <[hidden email]> 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 <[hidden email]> 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?



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

Peter Eisentraut <[hidden email]> 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 <[hidden email]> 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:
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