3 files changed, 48 insertions, 18 deletions
diff --git a/src/test/regress/sql/rangefuncs.sql b/src/test/regress/sql/rangefuncs.sql
index c8edc553bc..09ac8fbdb4 100644
--- a/src/test/regress/sql/rangefuncs.sql
+++ b/src/test/regress/sql/rangefuncs.sql
@@ -1,5 +1,3 @@
-SELECT name, setting FROM pg_settings WHERE name LIKE 'enable%';
-
 CREATE TABLE foo2(fooid int, f2 int);
 INSERT INTO foo2 VALUES(1, 11);
 INSERT INTO foo2 VALUES(2, 22);
diff --git a/src/test/regress/sql/sysviews.sql b/src/test/regress/sql/sysviews.sql
new file mode 100644
index 0000000000..0941b6beac
--- /dev/null
+++ b/src/test/regress/sql/sysviews.sql
@@ -0,0 +1,48 @@
+--
+-- Test assorted system views
+--
+-- This test is mainly meant to provide some code coverage for the
+-- set-returning functions that underlie certain system views.
+-- The output of most of these functions is very environment-dependent,
+-- so our ability to test with fixed expected output is pretty limited;
+-- but even a trivial check of count(*) will exercise the normal code path
+-- through the SRF.
+
+select count(*) >= 0 as ok from pg_available_extension_versions;
+
+select count(*) >= 0 as ok from pg_available_extensions;
+
+-- At introduction, pg_config had 23 entries; it may grow
+select count(*) > 20 as ok from pg_config;
+
+-- We expect no cursors in this test; see also portals.sql
+select count(*) = 0 as ok from pg_cursors;
+
+select count(*) >= 0 as ok from pg_file_settings;
+
+-- There will surely be at least one active lock
+select count(*) > 0 as ok from pg_locks;
+
+-- We expect no prepared statements in this test; see also prepare.sql
+select count(*) = 0 as ok from pg_prepared_statements;
+
+-- See also prepared_xacts.sql
+select count(*) >= 0 as ok from pg_prepared_xacts;
+
+-- This is to record the prevailing planner enable_foo settings during
+-- a regression test run.
+select name, setting from pg_settings where name like 'enable%';
+
+-- Test that the pg_timezone_names and pg_timezone_abbrevs views are
+-- more-or-less working.  We can't test their contents in any great detail
+-- without the outputs changing anytime IANA updates the underlying data,
+-- but it seems reasonable to expect at least one entry per major meridian.
+-- (At the time of writing, the actual counts are around 38 because of
+-- zones using fractional GMT offsets, so this is a pretty loose test.)
+select count(distinct utc_offset) >= 24 as ok from pg_timezone_names;
+select count(distinct utc_offset) >= 24 as ok from pg_timezone_abbrevs;
+-- Let's check the non-default timezone abbreviation sets, too
+set timezone_abbreviations = 'Australia';
+select count(distinct utc_offset) >= 24 as ok from pg_timezone_abbrevs;
+set timezone_abbreviations = 'India';
+select count(distinct utc_offset) >= 24 as ok from pg_timezone_abbrevs;
diff --git a/src/test/regress/sql/timestamptz.sql b/src/test/regress/sql/timestamptz.sql
index ab86622a88..5898747064 100644
--- a/src/test/regress/sql/timestamptz.sql
+++ b/src/test/regress/sql/timestamptz.sql
@@ -470,22 +470,6 @@ SELECT '2007-12-09 07:29:59 UTC'::timestamptz AT TIME ZONE 'VET';
 SELECT '2007-12-09 07:30:00 UTC'::timestamptz AT TIME ZONE 'VET';
 
 --
--- Test that the pg_timezone_names and pg_timezone_abbrevs views are
--- more-or-less working.  We can't test their contents in any great detail
--- without the outputs changing anytime IANA updates the underlying data,
--- but it seems reasonable to expect at least one entry per major meridian.
--- (At the time of writing, the actual counts are around 38 because of
--- zones using fractional GMT offsets, so this is a pretty loose test.)
---
-select count(distinct utc_offset) >= 24 as ok from pg_timezone_names;
-select count(distinct utc_offset) >= 24 as ok from pg_timezone_abbrevs;
--- Let's check the non-default timezone abbreviation sets, too
-set timezone_abbreviations = 'Australia';
-select count(distinct utc_offset) >= 24 as ok from pg_timezone_abbrevs;
-set timezone_abbreviations = 'India';
-select count(distinct utc_offset) >= 24 as ok from pg_timezone_abbrevs;
-
---
 -- Test that AT TIME ZONE isn't misoptimized when using an index (bug #14504)
 --
 create temp table tmptz (f1 timestamptz primary key);