plpgsql test layout

Started by Peter Eisentrautabout 8 years ago11 messages
#1Peter Eisentraut
peter.eisentraut@2ndquadrant.com

Something that has been bothering me for a while, while we have neatly
organized test files for plperl, plpython, pltcl, the plpgsql tests are
all in one giant file in the main test suite, which makes development
and testing of plpgsql cumbersome. It is by far the largest test file
after numeric_big now.

One option would be to create a new test setup under src/pl/pgsql(/src)
and move some of the test material from the main test suite there. Some
of the test cases in the main test suite are more about SPI and triggers
and such, so it makes sense to keep these in the main line. Of course
finding the cut-off might be hard. Or maybe we'll just start with new
stuff from now on.

Any thoughts?

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

#2Pavel Stehule
pavel.stehule@gmail.com
In reply to: Peter Eisentraut (#1)
Re: plpgsql test layout

2017-11-14 17:18 GMT+01:00 Peter Eisentraut <
peter.eisentraut@2ndquadrant.com>:

Something that has been bothering me for a while, while we have neatly
organized test files for plperl, plpython, pltcl, the plpgsql tests are
all in one giant file in the main test suite, which makes development
and testing of plpgsql cumbersome. It is by far the largest test file
after numeric_big now.

One option would be to create a new test setup under src/pl/pgsql(/src)
and move some of the test material from the main test suite there. Some
of the test cases in the main test suite are more about SPI and triggers
and such, so it makes sense to keep these in the main line. Of course
finding the cut-off might be hard. Or maybe we'll just start with new
stuff from now on.

Any thoughts?

+1

Pavel

Show quoted text

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

#3Peter Eisentraut
peter.eisentraut@2ndquadrant.com
In reply to: Pavel Stehule (#2)
1 attachment(s)
Re: plpgsql test layout

On 11/14/17 11:51, Pavel Stehule wrote:

One option would be to create a new test setup under src/pl/pgsql(/src)
and move some of the test material from the main test suite there.  Some
of the test cases in the main test suite are more about SPI and triggers
and such, so it makes sense to keep these in the main line.  Of course
finding the cut-off might be hard.  Or maybe we'll just start with new
stuff from now on.

Any thoughts?

+1

Here is a first attempt.

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

Attachments:

0001-Start-a-separate-test-suite-for-plpgsql.patchtext/plain; charset=UTF-8; name=0001-Start-a-separate-test-suite-for-plpgsql.patch; x-mac-creator=0; x-mac-type=0Download
From 00821d8a460f5e4f39376a87531cfd6be2354684 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <peter_e@gmx.net>
Date: Thu, 7 Dec 2017 14:03:29 -0500
Subject: [PATCH] Start a separate test suite for plpgsql

The plpgsql.sql test file in the main regression tests is now by far the
largest after numeric_big, making editing and managing the test cases
very cumbersome.  The other PLs have their own test suites split up into
smaller files by topic.  It would be nice to have that for plpgsql as
well.  So, to get that started, set up test infrastructure in
src/pl/plpgsql/src/ and split out the recently added procedure test
cases into a new file there.  That file now mirrors the test cases added
to the other PLs, making managing those matching tests a bit easier too.
---
 src/pl/plpgsql/src/.gitignore                |  3 ++
 src/pl/plpgsql/src/Makefile                  | 14 ++++++++
 src/pl/plpgsql/src/expected/plpgsql_call.out | 41 +++++++++++++++++++++++
 src/pl/plpgsql/src/sql/plpgsql_call.sql      | 47 ++++++++++++++++++++++++++
 src/test/regress/expected/plpgsql.out        | 41 -----------------------
 src/test/regress/sql/plpgsql.sql             | 49 ----------------------------
 6 files changed, 105 insertions(+), 90 deletions(-)
 create mode 100644 src/pl/plpgsql/src/expected/plpgsql_call.out
 create mode 100644 src/pl/plpgsql/src/sql/plpgsql_call.sql

diff --git a/src/pl/plpgsql/src/.gitignore b/src/pl/plpgsql/src/.gitignore
index 92387fa3cb..ff6ac965fd 100644
--- a/src/pl/plpgsql/src/.gitignore
+++ b/src/pl/plpgsql/src/.gitignore
@@ -1,3 +1,6 @@
 /pl_gram.c
 /pl_gram.h
 /plerrcodes.h
+/log/
+/results/
+/tmp_check/
diff --git a/src/pl/plpgsql/src/Makefile b/src/pl/plpgsql/src/Makefile
index 95348179ac..64991c3115 100644
--- a/src/pl/plpgsql/src/Makefile
+++ b/src/pl/plpgsql/src/Makefile
@@ -24,6 +24,8 @@ OBJS = pl_gram.o pl_handler.o pl_comp.o pl_exec.o \
 
 DATA = plpgsql.control plpgsql--1.0.sql plpgsql--unpackaged--1.0.sql
 
+REGRESS = plpgsql_call
+
 all: all-lib
 
 # Shared library stuff
@@ -65,6 +67,18 @@ pl_gram.c: BISONFLAGS += -d
 plerrcodes.h: $(top_srcdir)/src/backend/utils/errcodes.txt generate-plerrcodes.pl
 	$(PERL) $(srcdir)/generate-plerrcodes.pl $< > $@
 
+
+check: submake
+	$(pg_regress_check) $(REGRESS_OPTS) $(REGRESS)
+
+installcheck: submake
+	$(pg_regress_installcheck) $(REGRESS_OPTS) $(REGRESS)
+
+.PHONY: submake
+submake:
+	$(MAKE) -C $(top_builddir)/src/test/regress pg_regress$(X)
+
+
 distprep: pl_gram.h pl_gram.c plerrcodes.h
 
 # pl_gram.c, pl_gram.h and plerrcodes.h are in the distribution tarball,
diff --git a/src/pl/plpgsql/src/expected/plpgsql_call.out b/src/pl/plpgsql/src/expected/plpgsql_call.out
new file mode 100644
index 0000000000..d0f35163bc
--- /dev/null
+++ b/src/pl/plpgsql/src/expected/plpgsql_call.out
@@ -0,0 +1,41 @@
+--
+-- Tests for procedures / CALL syntax
+--
+CREATE PROCEDURE test_proc1()
+LANGUAGE plpgsql
+AS $$
+BEGIN
+    NULL;
+END;
+$$;
+CALL test_proc1();
+-- error: can't return non-NULL
+CREATE PROCEDURE test_proc2()
+LANGUAGE plpgsql
+AS $$
+BEGIN
+    RETURN 5;
+END;
+$$;
+CALL test_proc2();
+ERROR:  cannot return a value from a procedure
+CONTEXT:  PL/pgSQL function test_proc2() while casting return value to function's return type
+CREATE TABLE test1 (a int);
+CREATE PROCEDURE test_proc3(x int)
+LANGUAGE plpgsql
+AS $$
+BEGIN
+    INSERT INTO test1 VALUES (x);
+END;
+$$;
+CALL test_proc3(55);
+SELECT * FROM test1;
+ a  
+----
+ 55
+(1 row)
+
+DROP PROCEDURE test_proc1;
+DROP PROCEDURE test_proc2;
+DROP PROCEDURE test_proc3;
+DROP TABLE test1;
diff --git a/src/pl/plpgsql/src/sql/plpgsql_call.sql b/src/pl/plpgsql/src/sql/plpgsql_call.sql
new file mode 100644
index 0000000000..38fd220e8f
--- /dev/null
+++ b/src/pl/plpgsql/src/sql/plpgsql_call.sql
@@ -0,0 +1,47 @@
+--
+-- Tests for procedures / CALL syntax
+--
+
+CREATE PROCEDURE test_proc1()
+LANGUAGE plpgsql
+AS $$
+BEGIN
+    NULL;
+END;
+$$;
+
+CALL test_proc1();
+
+
+-- error: can't return non-NULL
+CREATE PROCEDURE test_proc2()
+LANGUAGE plpgsql
+AS $$
+BEGIN
+    RETURN 5;
+END;
+$$;
+
+CALL test_proc2();
+
+
+CREATE TABLE test1 (a int);
+
+CREATE PROCEDURE test_proc3(x int)
+LANGUAGE plpgsql
+AS $$
+BEGIN
+    INSERT INTO test1 VALUES (x);
+END;
+$$;
+
+CALL test_proc3(55);
+
+SELECT * FROM test1;
+
+
+DROP PROCEDURE test_proc1;
+DROP PROCEDURE test_proc2;
+DROP PROCEDURE test_proc3;
+
+DROP TABLE test1;
diff --git a/src/test/regress/expected/plpgsql.out b/src/test/regress/expected/plpgsql.out
index d6e5bc3353..bb3532676b 100644
--- a/src/test/regress/expected/plpgsql.out
+++ b/src/test/regress/expected/plpgsql.out
@@ -6040,44 +6040,3 @@ END; $$ LANGUAGE plpgsql;
 ERROR:  "x" is not a scalar variable
 LINE 3:   GET DIAGNOSTICS x = ROW_COUNT;
                           ^
---
--- Procedures
---
-CREATE PROCEDURE test_proc1()
-LANGUAGE plpgsql
-AS $$
-BEGIN
-    NULL;
-END;
-$$;
-CALL test_proc1();
--- error: can't return non-NULL
-CREATE PROCEDURE test_proc2()
-LANGUAGE plpgsql
-AS $$
-BEGIN
-    RETURN 5;
-END;
-$$;
-CALL test_proc2();
-ERROR:  cannot return a value from a procedure
-CONTEXT:  PL/pgSQL function test_proc2() while casting return value to function's return type
-CREATE TABLE proc_test1 (a int);
-CREATE PROCEDURE test_proc3(x int)
-LANGUAGE plpgsql
-AS $$
-BEGIN
-    INSERT INTO proc_test1 VALUES (x);
-END;
-$$;
-CALL test_proc3(55);
-SELECT * FROM proc_test1;
- a  
-----
- 55
-(1 row)
-
-DROP PROCEDURE test_proc1;
-DROP PROCEDURE test_proc2;
-DROP PROCEDURE test_proc3;
-DROP TABLE proc_test1;
diff --git a/src/test/regress/sql/plpgsql.sql b/src/test/regress/sql/plpgsql.sql
index 1c355132b7..6620ea6172 100644
--- a/src/test/regress/sql/plpgsql.sql
+++ b/src/test/regress/sql/plpgsql.sql
@@ -4820,52 +4820,3 @@ CREATE FUNCTION fx(x WSlot) RETURNS void AS $$
   GET DIAGNOSTICS x = ROW_COUNT;
   RETURN;
 END; $$ LANGUAGE plpgsql;
-
-
---
--- Procedures
---
-
-CREATE PROCEDURE test_proc1()
-LANGUAGE plpgsql
-AS $$
-BEGIN
-    NULL;
-END;
-$$;
-
-CALL test_proc1();
-
-
--- error: can't return non-NULL
-CREATE PROCEDURE test_proc2()
-LANGUAGE plpgsql
-AS $$
-BEGIN
-    RETURN 5;
-END;
-$$;
-
-CALL test_proc2();
-
-
-CREATE TABLE proc_test1 (a int);
-
-CREATE PROCEDURE test_proc3(x int)
-LANGUAGE plpgsql
-AS $$
-BEGIN
-    INSERT INTO proc_test1 VALUES (x);
-END;
-$$;
-
-CALL test_proc3(55);
-
-SELECT * FROM proc_test1;
-
-
-DROP PROCEDURE test_proc1;
-DROP PROCEDURE test_proc2;
-DROP PROCEDURE test_proc3;
-
-DROP TABLE proc_test1;
-- 
2.15.1

#4Pavel Stehule
pavel.stehule@gmail.com
In reply to: Peter Eisentraut (#3)
Re: plpgsql test layout

2017-12-07 20:08 GMT+01:00 Peter Eisentraut <
peter.eisentraut@2ndquadrant.com>:

On 11/14/17 11:51, Pavel Stehule wrote:

One option would be to create a new test setup under

src/pl/pgsql(/src)

and move some of the test material from the main test suite there.

Some

of the test cases in the main test suite are more about SPI and

triggers

and such, so it makes sense to keep these in the main line. Of

course

finding the cut-off might be hard. Or maybe we'll just start with

new

stuff from now on.

Any thoughts?

+1

Here is a first attempt.

looks ok

Show quoted text

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

#5Peter Eisentraut
peter.eisentraut@2ndquadrant.com
In reply to: Pavel Stehule (#4)
Re: plpgsql test layout

On 12/7/17 15:21, Pavel Stehule wrote:

2017-12-07 20:08 GMT+01:00 Peter Eisentraut
<peter.eisentraut@2ndquadrant.com
<mailto:peter.eisentraut@2ndquadrant.com>>:

On 11/14/17 11:51, Pavel Stehule wrote:

     One option would be to create a new test setup under src/pl/pgsql(/src)
     and move some of the test material from the main test suite there.  Some
     of the test cases in the main test suite are more about SPI and triggers
     and such, so it makes sense to keep these in the main line.  Of course
     finding the cut-off might be hard.  Or maybe we'll just start with new
     stuff from now on.

     Any thoughts?

+1

Here is a first attempt.

looks ok

Any other thoughts on this? If not, I'd like to commit it, give the
buildfarm a run at it (looking at the client code, it should be fine),
and then rebase some ongoing work on top of it.

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

#6Tom Lane
tgl@sss.pgh.pa.us
In reply to: Peter Eisentraut (#5)
Re: plpgsql test layout

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

On 12/7/17 15:21, Pavel Stehule wrote:

2017-12-07 20:08 GMT+01:00 Peter Eisentraut
<peter.eisentraut@2ndquadrant.com
<mailto:peter.eisentraut@2ndquadrant.com>>:

Here is a first attempt.

looks ok

Any other thoughts on this? If not, I'd like to commit it, give the
buildfarm a run at it (looking at the client code, it should be fine),
and then rebase some ongoing work on top of it.

No particular objection. Does the MSVC infrastructure need to be
taught about it?

regards, tom lane

#7Michael Paquier
michael.paquier@gmail.com
In reply to: Tom Lane (#6)
Re: plpgsql test layout

On Tue, Dec 12, 2017 at 5:11 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

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

On 12/7/17 15:21, Pavel Stehule wrote:

2017-12-07 20:08 GMT+01:00 Peter Eisentraut
<peter.eisentraut@2ndquadrant.com
<mailto:peter.eisentraut@2ndquadrant.com>>:

Here is a first attempt.

looks ok

Any other thoughts on this? If not, I'd like to commit it, give the
buildfarm a run at it (looking at the client code, it should be fine),
and then rebase some ongoing work on top of it.

No particular objection. Does the MSVC infrastructure need to be
taught about it?

If I read vcregress.pl correctly, it seems to me that you need to do
more with MSVC (see plcheck). The tests would kick if sql/ and
expected/ are found, and the test list is fetched by looking at
REGRESSION in the test files. However plpgsql code has an additional
src/ folder which would cause the tests to not execute. If plpgsql
code was moved on folder down then the tests would execute properly.
--
Michael

#8Peter Eisentraut
peter.eisentraut@2ndquadrant.com
In reply to: Michael Paquier (#7)
1 attachment(s)
Re: plpgsql test layout

On 12/11/17 19:29, Michael Paquier wrote:

If I read vcregress.pl correctly, it seems to me that you need to do
more with MSVC (see plcheck). The tests would kick if sql/ and
expected/ are found, and the test list is fetched by looking at
REGRESSION in the test files. However plpgsql code has an additional
src/ folder which would cause the tests to not execute. If plpgsql
code was moved on folder down then the tests would execute properly.

OK, I hacked something up for MSVC. How about this?

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

Attachments:

v2-0001-Start-a-separate-test-suite-for-plpgsql.patchtext/plain; charset=UTF-8; name=v2-0001-Start-a-separate-test-suite-for-plpgsql.patch; x-mac-creator=0; x-mac-type=0Download
From 90383a92d457ac0cc23faf72b68e87a12f000def Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <peter_e@gmx.net>
Date: Thu, 7 Dec 2017 14:03:29 -0500
Subject: [PATCH v2] Start a separate test suite for plpgsql

The plpgsql.sql test file in the main regression tests is now by far the
largest after numeric_big, making editing and managing the test cases
very cumbersome.  The other PLs have their own test suites split up into
smaller files by topic.  It would be nice to have that for plpgsql as
well.  So, to get that started, set up test infrastructure in
src/pl/plpgsql/src/ and split out the recently added procedure test
cases into a new file there.  That file now mirrors the test cases added
to the other PLs, making managing those matching tests a bit easier too.
---
 src/pl/plpgsql/src/.gitignore                |  3 ++
 src/pl/plpgsql/src/Makefile                  | 14 ++++++++
 src/pl/plpgsql/src/expected/plpgsql_call.out | 41 +++++++++++++++++++++++
 src/pl/plpgsql/src/sql/plpgsql_call.sql      | 47 ++++++++++++++++++++++++++
 src/test/regress/expected/plpgsql.out        | 41 -----------------------
 src/test/regress/sql/plpgsql.sql             | 49 ----------------------------
 src/tools/msvc/vcregress.pl                  | 18 +++++++---
 7 files changed, 119 insertions(+), 94 deletions(-)
 create mode 100644 src/pl/plpgsql/src/expected/plpgsql_call.out
 create mode 100644 src/pl/plpgsql/src/sql/plpgsql_call.sql

diff --git a/src/pl/plpgsql/src/.gitignore b/src/pl/plpgsql/src/.gitignore
index 92387fa3cb..ff6ac965fd 100644
--- a/src/pl/plpgsql/src/.gitignore
+++ b/src/pl/plpgsql/src/.gitignore
@@ -1,3 +1,6 @@
 /pl_gram.c
 /pl_gram.h
 /plerrcodes.h
+/log/
+/results/
+/tmp_check/
diff --git a/src/pl/plpgsql/src/Makefile b/src/pl/plpgsql/src/Makefile
index 95348179ac..64991c3115 100644
--- a/src/pl/plpgsql/src/Makefile
+++ b/src/pl/plpgsql/src/Makefile
@@ -24,6 +24,8 @@ OBJS = pl_gram.o pl_handler.o pl_comp.o pl_exec.o \
 
 DATA = plpgsql.control plpgsql--1.0.sql plpgsql--unpackaged--1.0.sql
 
+REGRESS = plpgsql_call
+
 all: all-lib
 
 # Shared library stuff
@@ -65,6 +67,18 @@ pl_gram.c: BISONFLAGS += -d
 plerrcodes.h: $(top_srcdir)/src/backend/utils/errcodes.txt generate-plerrcodes.pl
 	$(PERL) $(srcdir)/generate-plerrcodes.pl $< > $@
 
+
+check: submake
+	$(pg_regress_check) $(REGRESS_OPTS) $(REGRESS)
+
+installcheck: submake
+	$(pg_regress_installcheck) $(REGRESS_OPTS) $(REGRESS)
+
+.PHONY: submake
+submake:
+	$(MAKE) -C $(top_builddir)/src/test/regress pg_regress$(X)
+
+
 distprep: pl_gram.h pl_gram.c plerrcodes.h
 
 # pl_gram.c, pl_gram.h and plerrcodes.h are in the distribution tarball,
diff --git a/src/pl/plpgsql/src/expected/plpgsql_call.out b/src/pl/plpgsql/src/expected/plpgsql_call.out
new file mode 100644
index 0000000000..d0f35163bc
--- /dev/null
+++ b/src/pl/plpgsql/src/expected/plpgsql_call.out
@@ -0,0 +1,41 @@
+--
+-- Tests for procedures / CALL syntax
+--
+CREATE PROCEDURE test_proc1()
+LANGUAGE plpgsql
+AS $$
+BEGIN
+    NULL;
+END;
+$$;
+CALL test_proc1();
+-- error: can't return non-NULL
+CREATE PROCEDURE test_proc2()
+LANGUAGE plpgsql
+AS $$
+BEGIN
+    RETURN 5;
+END;
+$$;
+CALL test_proc2();
+ERROR:  cannot return a value from a procedure
+CONTEXT:  PL/pgSQL function test_proc2() while casting return value to function's return type
+CREATE TABLE test1 (a int);
+CREATE PROCEDURE test_proc3(x int)
+LANGUAGE plpgsql
+AS $$
+BEGIN
+    INSERT INTO test1 VALUES (x);
+END;
+$$;
+CALL test_proc3(55);
+SELECT * FROM test1;
+ a  
+----
+ 55
+(1 row)
+
+DROP PROCEDURE test_proc1;
+DROP PROCEDURE test_proc2;
+DROP PROCEDURE test_proc3;
+DROP TABLE test1;
diff --git a/src/pl/plpgsql/src/sql/plpgsql_call.sql b/src/pl/plpgsql/src/sql/plpgsql_call.sql
new file mode 100644
index 0000000000..38fd220e8f
--- /dev/null
+++ b/src/pl/plpgsql/src/sql/plpgsql_call.sql
@@ -0,0 +1,47 @@
+--
+-- Tests for procedures / CALL syntax
+--
+
+CREATE PROCEDURE test_proc1()
+LANGUAGE plpgsql
+AS $$
+BEGIN
+    NULL;
+END;
+$$;
+
+CALL test_proc1();
+
+
+-- error: can't return non-NULL
+CREATE PROCEDURE test_proc2()
+LANGUAGE plpgsql
+AS $$
+BEGIN
+    RETURN 5;
+END;
+$$;
+
+CALL test_proc2();
+
+
+CREATE TABLE test1 (a int);
+
+CREATE PROCEDURE test_proc3(x int)
+LANGUAGE plpgsql
+AS $$
+BEGIN
+    INSERT INTO test1 VALUES (x);
+END;
+$$;
+
+CALL test_proc3(55);
+
+SELECT * FROM test1;
+
+
+DROP PROCEDURE test_proc1;
+DROP PROCEDURE test_proc2;
+DROP PROCEDURE test_proc3;
+
+DROP TABLE test1;
diff --git a/src/test/regress/expected/plpgsql.out b/src/test/regress/expected/plpgsql.out
index d6e5bc3353..bb3532676b 100644
--- a/src/test/regress/expected/plpgsql.out
+++ b/src/test/regress/expected/plpgsql.out
@@ -6040,44 +6040,3 @@ END; $$ LANGUAGE plpgsql;
 ERROR:  "x" is not a scalar variable
 LINE 3:   GET DIAGNOSTICS x = ROW_COUNT;
                           ^
---
--- Procedures
---
-CREATE PROCEDURE test_proc1()
-LANGUAGE plpgsql
-AS $$
-BEGIN
-    NULL;
-END;
-$$;
-CALL test_proc1();
--- error: can't return non-NULL
-CREATE PROCEDURE test_proc2()
-LANGUAGE plpgsql
-AS $$
-BEGIN
-    RETURN 5;
-END;
-$$;
-CALL test_proc2();
-ERROR:  cannot return a value from a procedure
-CONTEXT:  PL/pgSQL function test_proc2() while casting return value to function's return type
-CREATE TABLE proc_test1 (a int);
-CREATE PROCEDURE test_proc3(x int)
-LANGUAGE plpgsql
-AS $$
-BEGIN
-    INSERT INTO proc_test1 VALUES (x);
-END;
-$$;
-CALL test_proc3(55);
-SELECT * FROM proc_test1;
- a  
-----
- 55
-(1 row)
-
-DROP PROCEDURE test_proc1;
-DROP PROCEDURE test_proc2;
-DROP PROCEDURE test_proc3;
-DROP TABLE proc_test1;
diff --git a/src/test/regress/sql/plpgsql.sql b/src/test/regress/sql/plpgsql.sql
index 1c355132b7..6620ea6172 100644
--- a/src/test/regress/sql/plpgsql.sql
+++ b/src/test/regress/sql/plpgsql.sql
@@ -4820,52 +4820,3 @@ CREATE FUNCTION fx(x WSlot) RETURNS void AS $$
   GET DIAGNOSTICS x = ROW_COUNT;
   RETURN;
 END; $$ LANGUAGE plpgsql;
-
-
---
--- Procedures
---
-
-CREATE PROCEDURE test_proc1()
-LANGUAGE plpgsql
-AS $$
-BEGIN
-    NULL;
-END;
-$$;
-
-CALL test_proc1();
-
-
--- error: can't return non-NULL
-CREATE PROCEDURE test_proc2()
-LANGUAGE plpgsql
-AS $$
-BEGIN
-    RETURN 5;
-END;
-$$;
-
-CALL test_proc2();
-
-
-CREATE TABLE proc_test1 (a int);
-
-CREATE PROCEDURE test_proc3(x int)
-LANGUAGE plpgsql
-AS $$
-BEGIN
-    INSERT INTO proc_test1 VALUES (x);
-END;
-$$;
-
-CALL test_proc3(55);
-
-SELECT * FROM proc_test1;
-
-
-DROP PROCEDURE test_proc1;
-DROP PROCEDURE test_proc2;
-DROP PROCEDURE test_proc3;
-
-DROP TABLE proc_test1;
diff --git a/src/tools/msvc/vcregress.pl b/src/tools/msvc/vcregress.pl
index 719fe83047..2f63b08065 100644
--- a/src/tools/msvc/vcregress.pl
+++ b/src/tools/msvc/vcregress.pl
@@ -250,10 +250,19 @@ sub plcheck
 {
 	chdir "../../pl";
 
-	foreach my $pl (glob("*"))
+	foreach my $dir (glob("*/src *"))
 	{
-		next unless -d "$pl/sql" && -d "$pl/expected";
-		my $lang = $pl eq 'tcl' ? 'pltcl' : $pl;
+		next unless -d "$dir/sql" && -d "$dir/expected";
+		my $lang;
+		if ($dir eq 'plpgsql/src') {
+			$lang = 'plpgsql';
+		}
+		elsif ($dir eq 'tcl') {
+			$lang = 'pltcl';
+		}
+		else {
+			$lang = $dir;
+		}
 		if ($lang eq 'plpython')
 		{
 			next unless -d "../../$Config/plpython2";
@@ -264,7 +273,7 @@ sub plcheck
 			next unless -d "../../$Config/$lang";
 		}
 		my @lang_args = ("--load-extension=$lang");
-		chdir $pl;
+		chdir $dir;
 		my @tests = fetchTests();
 		if ($lang eq 'plperl')
 		{
@@ -292,6 +301,7 @@ sub plcheck
 		my $status = $? >> 8;
 		exit $status if $status;
 		chdir "..";
+		chdir ".." if $lang eq 'plpgsql';
 	}
 
 	chdir "../../..";
-- 
2.15.1

#9Tom Lane
tgl@sss.pgh.pa.us
In reply to: Peter Eisentraut (#8)
Re: plpgsql test layout

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

On 12/11/17 19:29, Michael Paquier wrote:

If I read vcregress.pl correctly, it seems to me that you need to do
more with MSVC (see plcheck). The tests would kick if sql/ and
expected/ are found, and the test list is fetched by looking at
REGRESSION in the test files. However plpgsql code has an additional
src/ folder which would cause the tests to not execute. If plpgsql
code was moved on folder down then the tests would execute properly.

OK, I hacked something up for MSVC. How about this?

Looks ok to me, though I'm not in a position to actually test the
msvc changes.

regards, tom lane

#10Michael Paquier
michael.paquier@gmail.com
In reply to: Tom Lane (#9)
1 attachment(s)
Re: plpgsql test layout

On Wed, Dec 13, 2017 at 6:36 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

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

On 12/11/17 19:29, Michael Paquier wrote:

If I read vcregress.pl correctly, it seems to me that you need to do
more with MSVC (see plcheck). The tests would kick if sql/ and
expected/ are found, and the test list is fetched by looking at
REGRESSION in the test files. However plpgsql code has an additional
src/ folder which would cause the tests to not execute. If plpgsql
code was moved on folder down then the tests would execute properly.

OK, I hacked something up for MSVC. How about this?

Looks ok to me, though I'm not in a position to actually test the
msvc changes.

I have been able to check that the tests are working correctly, but
after changing the references from relative paths to absolute paths,
or my environment is complaining about ".." not being a command...

my $status = $? >> 8;
exit $status if $status;
chdir "..";
+ chdir ".." if $lang eq 'plpgsql';
}
This can be replaced with a single "$topdir/src/pl".

Attached is what I have some up with, based on Peter's v2.
--
Michael

Attachments:

plpgsql-msvc-michael.patchapplication/octet-stream; name=plpgsql-msvc-michael.patchDownload
diff --git a/src/pl/plpgsql/src/.gitignore b/src/pl/plpgsql/src/.gitignore
index 92387fa..ff6ac96 100644
--- a/src/pl/plpgsql/src/.gitignore
+++ b/src/pl/plpgsql/src/.gitignore
@@ -1,3 +1,6 @@
 /pl_gram.c
 /pl_gram.h
 /plerrcodes.h
+/log/
+/results/
+/tmp_check/
diff --git a/src/pl/plpgsql/src/Makefile b/src/pl/plpgsql/src/Makefile
index 9534817..64991c3 100644
--- a/src/pl/plpgsql/src/Makefile
+++ b/src/pl/plpgsql/src/Makefile
@@ -24,6 +24,8 @@ OBJS = pl_gram.o pl_handler.o pl_comp.o pl_exec.o \
 
 DATA = plpgsql.control plpgsql--1.0.sql plpgsql--unpackaged--1.0.sql
 
+REGRESS = plpgsql_call
+
 all: all-lib
 
 # Shared library stuff
@@ -65,6 +67,18 @@ pl_gram.c: BISONFLAGS += -d
 plerrcodes.h: $(top_srcdir)/src/backend/utils/errcodes.txt generate-plerrcodes.pl
 	$(PERL) $(srcdir)/generate-plerrcodes.pl $< > $@
 
+
+check: submake
+	$(pg_regress_check) $(REGRESS_OPTS) $(REGRESS)
+
+installcheck: submake
+	$(pg_regress_installcheck) $(REGRESS_OPTS) $(REGRESS)
+
+.PHONY: submake
+submake:
+	$(MAKE) -C $(top_builddir)/src/test/regress pg_regress$(X)
+
+
 distprep: pl_gram.h pl_gram.c plerrcodes.h
 
 # pl_gram.c, pl_gram.h and plerrcodes.h are in the distribution tarball,
diff --git a/src/test/regress/expected/plpgsql.out b/src/test/regress/expected/plpgsql.out
index 26f6e43..a2df411 100644
--- a/src/test/regress/expected/plpgsql.out
+++ b/src/test/regress/expected/plpgsql.out
@@ -6067,44 +6067,3 @@ END; $$ LANGUAGE plpgsql;
 ERROR:  "x" is not a scalar variable
 LINE 3:   GET DIAGNOSTICS x = ROW_COUNT;
                           ^
---
--- Procedures
---
-CREATE PROCEDURE test_proc1()
-LANGUAGE plpgsql
-AS $$
-BEGIN
-    NULL;
-END;
-$$;
-CALL test_proc1();
--- error: can't return non-NULL
-CREATE PROCEDURE test_proc2()
-LANGUAGE plpgsql
-AS $$
-BEGIN
-    RETURN 5;
-END;
-$$;
-CALL test_proc2();
-ERROR:  cannot return a value from a procedure
-CONTEXT:  PL/pgSQL function test_proc2() while casting return value to function's return type
-CREATE TABLE proc_test1 (a int);
-CREATE PROCEDURE test_proc3(x int)
-LANGUAGE plpgsql
-AS $$
-BEGIN
-    INSERT INTO proc_test1 VALUES (x);
-END;
-$$;
-CALL test_proc3(55);
-SELECT * FROM proc_test1;
- a  
-----
- 55
-(1 row)
-
-DROP PROCEDURE test_proc1;
-DROP PROCEDURE test_proc2;
-DROP PROCEDURE test_proc3;
-DROP TABLE proc_test1;
diff --git a/src/test/regress/sql/plpgsql.sql b/src/test/regress/sql/plpgsql.sql
index bb09b2d..02c8913 100644
--- a/src/test/regress/sql/plpgsql.sql
+++ b/src/test/regress/sql/plpgsql.sql
@@ -4843,52 +4843,3 @@ BEGIN
   GET DIAGNOSTICS x = ROW_COUNT;
   RETURN;
 END; $$ LANGUAGE plpgsql;
-
-
---
--- Procedures
---
-
-CREATE PROCEDURE test_proc1()
-LANGUAGE plpgsql
-AS $$
-BEGIN
-    NULL;
-END;
-$$;
-
-CALL test_proc1();
-
-
--- error: can't return non-NULL
-CREATE PROCEDURE test_proc2()
-LANGUAGE plpgsql
-AS $$
-BEGIN
-    RETURN 5;
-END;
-$$;
-
-CALL test_proc2();
-
-
-CREATE TABLE proc_test1 (a int);
-
-CREATE PROCEDURE test_proc3(x int)
-LANGUAGE plpgsql
-AS $$
-BEGIN
-    INSERT INTO proc_test1 VALUES (x);
-END;
-$$;
-
-CALL test_proc3(55);
-
-SELECT * FROM proc_test1;
-
-
-DROP PROCEDURE test_proc1;
-DROP PROCEDURE test_proc2;
-DROP PROCEDURE test_proc3;
-
-DROP TABLE proc_test1;
diff --git a/src/tools/msvc/vcregress.pl b/src/tools/msvc/vcregress.pl
index 719fe83..314f2c3 100644
--- a/src/tools/msvc/vcregress.pl
+++ b/src/tools/msvc/vcregress.pl
@@ -248,23 +248,32 @@ sub taptest
 
 sub plcheck
 {
-	chdir "../../pl";
+	chdir "$topdir/src/pl";
 
-	foreach my $pl (glob("*"))
+	foreach my $dir (glob("*/src *"))
 	{
-		next unless -d "$pl/sql" && -d "$pl/expected";
-		my $lang = $pl eq 'tcl' ? 'pltcl' : $pl;
+		next unless -d "$dir/sql" && -d "$dir/expected";
+		my $lang;
+		if ($dir eq 'plpgsql/src') {
+			$lang = 'plpgsql';
+		}
+		elsif ($dir eq 'tcl') {
+			$lang = 'pltcl';
+		}
+		else {
+			$lang = $dir;
+		}
 		if ($lang eq 'plpython')
 		{
-			next unless -d "../../$Config/plpython2";
+			next unless -d "$topdir/$Config/plpython2";
 			$lang = 'plpythonu';
 		}
 		else
 		{
-			next unless -d "../../$Config/$lang";
+			next unless -d "$topdir/$Config/$lang";
 		}
 		my @lang_args = ("--load-extension=$lang");
-		chdir $pl;
+		chdir $dir;
 		my @tests = fetchTests();
 		if ($lang eq 'plperl')
 		{
@@ -285,16 +294,16 @@ sub plcheck
 		  "============================================================\n";
 		print "Checking $lang\n";
 		my @args = (
-			"../../../$Config/pg_regress/pg_regress",
-			"--bindir=../../../$Config/psql",
+			"$topdir/$Config/pg_regress/pg_regress",
+			"--bindir=$topdir/$Config/psql",
 			"--dbname=pl_regression", @lang_args, @tests);
 		system(@args);
 		my $status = $? >> 8;
 		exit $status if $status;
-		chdir "..";
+		chdir "$topdir/src/pl";
 	}
 
-	chdir "../../..";
+	chdir "$topdir";
 }
 
 sub subdircheck
#11Peter Eisentraut
peter.eisentraut@2ndquadrant.com
In reply to: Michael Paquier (#10)
Re: plpgsql test layout

On 12/12/17 22:59, Michael Paquier wrote:

Attached is what I have some up with, based on Peter's v2.

This has been committed. Thanks!

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