Thread: plpgsql test layout

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

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

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

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

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

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

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

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

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