Add a regression test script dedicated to exercising system views.
authorTom Lane <tgl@sss.pgh.pa.us>
Mon, 30 Jan 2017 22:15:42 +0000 (17:15 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Mon, 30 Jan 2017 22:15:42 +0000 (17:15 -0500)
commitd002f16c6ec38f76d1ee97367ba6af3000d441d0
treeb80bd65c8c77003acb47c27c6a18a084ae5d3b7c
parent511ae628f31b4e791cd5c7836e46cb84dcf145fd
Add a regression test script dedicated to exercising system views.

Quite a few of our built-in system views were not exercised anywhere
in the regression tests.  This is perhaps not so exciting for the ones
that are simple projections/joins of system catalogs, but for the ones
that are wrappers for set-returning C functions, the omission translates
directly to lack of test coverage for those functions.

In many cases, the reason for the omission is that the view doesn't have
much to do with any specific SQL feature, so there's no natural place to
test it.  To remedy that, invent a new script sysviews.sql that's dedicated
to testing SRF-based views.  Move a couple of tests that did fit this
charter into the new script, and add simple "count(*)" based tests of
other views within the charter.  That's enough to ensure we at least
exercise the main code path through the SRF, although it does little to
prove that the output is sane.

More could be done here, no doubt, and I hope someone will think about
how we can test these views more thoroughly.  But this is a starting
point.

Discussion: https://postgr.es/m/19359.1485723741@sss.pgh.pa.us
src/test/regress/expected/rangefuncs.out
src/test/regress/expected/sysviews.out [new file with mode: 0644]
src/test/regress/expected/timestamptz.out
src/test/regress/parallel_schedule
src/test/regress/serial_schedule
src/test/regress/sql/rangefuncs.sql
src/test/regress/sql/sysviews.sql [new file with mode: 0644]
src/test/regress/sql/timestamptz.sql