Re: convert libpq uri-regress tests to tap test

[Michael Paquier]

On Thu, Jun 02, 2022 at 09:48:25AM -0700, Andres Freund wrote:
> On 2022-06-01 13:59:06 +0900, Michael Paquier wrote:
>> So, this leads to something like the attached.  Does that sound fine
>> to you?
> 
> That looks reasonable to me. Do you want to apply it or will you?

Thanks for double-checking!  I should be able to take care of that
today.
--
Michael


signature.asc
Description: PGP signature

Re: convert libpq uri-regress tests to tap test

[Andres Freund]

Hi,

On 2022-06-01 13:59:06 +0900, Michael Paquier wrote:
> On Tue, May 31, 2022 at 01:58:25PM +0900, Michael Paquier wrote:
> > Why don't you just use src/interfaces/ instead of adding a direct
> > path to libpq?
> 
> So, this leads to something like the attached.  Does that sound fine
> to you?

That looks reasonable to me. Do you want to apply it or will you?

Regards,

Andres

Re: convert libpq uri-regress tests to tap test

[Andres Freund]

Hi,

On 2022-05-29 10:18:50 -0500, Justin Pryzby wrote:
> On Sat, Feb 26, 2022 at 05:46:26PM -0800, Andres Freund wrote:
> > On 2022-02-25 17:52:29 -0800, Andres Freund wrote:
> > > I'd like to commit 0001 and 0002 soon, unless somebody sees a reason not 
> > > to?
> > 
> > Pushed.
> 
> If I'm not wrong, this isn't being run by check-world.

Oops, yes. Thanks for catching!

Re: convert libpq uri-regress tests to tap test

[Michael Paquier]

On Tue, May 31, 2022 at 01:58:25PM +0900, Michael Paquier wrote:
> Why don't you just use src/interfaces/ instead of adding a direct
> path to libpq?

So, this leads to something like the attached.  Does that sound fine
to you?
--
Michael
From 893ef90ce07084c4e4837205a805c590798ac115 Mon Sep 17 00:00:00 2001
From: Michael Paquier 
Date: Wed, 1 Jun 2022 13:57:46 +0900
Subject: [PATCH v2] libpq tests were not being run

---
 GNUmakefile.in | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/GNUmakefile.in b/GNUmakefile.in
index 2352fc1171..38713b5d12 100644
--- a/GNUmakefile.in
+++ b/GNUmakefile.in
@@ -68,10 +68,10 @@ check check-tests installcheck installcheck-parallel installcheck-tests: CHECKPR
 check check-tests installcheck installcheck-parallel installcheck-tests: submake-generated-headers
 	$(MAKE) -C src/test/regress $@
 
-$(call recurse,check-world,src/test src/pl src/interfaces/ecpg contrib src/bin,check)
-$(call recurse,checkprep,  src/test src/pl src/interfaces/ecpg contrib src/bin)
+$(call recurse,check-world,src/test src/pl src/interfaces contrib src/bin,check)
+$(call recurse,checkprep,  src/test src/pl src/interfaces contrib src/bin)
 
-$(call recurse,installcheck-world,src/test src/pl src/interfaces/ecpg contrib src/bin,installcheck)
+$(call recurse,installcheck-world,src/test src/pl src/interfaces contrib src/bin,installcheck)
 $(call recurse,install-tests,src/test/regress,install-tests)
 
 GNUmakefile: GNUmakefile.in $(top_builddir)/config.status
-- 
2.36.1



signature.asc
Description: PGP signature

Re: convert libpq uri-regress tests to tap test

[Michael Paquier]

On Sun, May 29, 2022 at 10:18:50AM -0500, Justin Pryzby wrote:
> On Sat, Feb 26, 2022 at 05:46:26PM -0800, Andres Freund wrote:
> > On 2022-02-25 17:52:29 -0800, Andres Freund wrote:
> > > I'd like to commit 0001 and 0002 soon, unless somebody sees a reason not 
> > > to?
> > 
> > Pushed.
> 
> If I'm not wrong, this isn't being run by check-world.

You are right.

> -$(call recurse,check-world,src/test src/pl src/interfaces/ecpg contrib 
> src/bin,check)
> -$(call recurse,checkprep,  src/test src/pl src/interfaces/ecpg contrib 
> src/bin)
> +$(call recurse,check-world,src/test src/pl src/interfaces/ecpg 
> src/interfaces/libpq contrib src/bin,check)
> +$(call recurse,checkprep,  src/test src/pl src/interfaces/ecpg 
> src/interfaces/libpq contrib src/bin)
>  
> -$(call recurse,installcheck-world,src/test src/pl src/interfaces/ecpg 
> contrib src/bin,installcheck)
> +$(call recurse,installcheck-world,src/test src/pl src/interfaces/ecpg 
> src/interfaces/libpq contrib src/bin,installcheck)
>  $(call recurse,install-tests,src/test/regress,install-tests)

Why don't you just use src/interfaces/ instead of adding a direct
path to libpq?
--
Michael


signature.asc
Description: PGP signature

Re: convert libpq uri-regress tests to tap test

[Justin Pryzby]

On Sat, Feb 26, 2022 at 05:46:26PM -0800, Andres Freund wrote:
> On 2022-02-25 17:52:29 -0800, Andres Freund wrote:
> > I'd like to commit 0001 and 0002 soon, unless somebody sees a reason not to?
> 
> Pushed.

If I'm not wrong, this isn't being run by check-world.

commit 4dc465207517c4b69a1f2b657a8ad0700c08e34c
Author: Justin Pryzby 
Date:   Sat May 28 22:32:58 2022 -0500

libpq tests were not being run

See also:
ac25173cdbc40b310a7e72d9557c45a699f1f7b3
6b04abdfc5e0653542ac5d586e639185a8c61a39

diff --git a/GNUmakefile.in b/GNUmakefile.in
index 2352fc1171a..cb613086c7c 100644
--- a/GNUmakefile.in
+++ b/GNUmakefile.in
@@ -68,10 +68,10 @@ check check-tests installcheck installcheck-parallel 
installcheck-tests: CHECKPR
 check check-tests installcheck installcheck-parallel installcheck-tests: 
submake-generated-headers
$(MAKE) -C src/test/regress $@
 
-$(call recurse,check-world,src/test src/pl src/interfaces/ecpg contrib 
src/bin,check)
-$(call recurse,checkprep,  src/test src/pl src/interfaces/ecpg contrib src/bin)
+$(call recurse,check-world,src/test src/pl src/interfaces/ecpg 
src/interfaces/libpq contrib src/bin,check)
+$(call recurse,checkprep,  src/test src/pl src/interfaces/ecpg 
src/interfaces/libpq contrib src/bin)
 
-$(call recurse,installcheck-world,src/test src/pl src/interfaces/ecpg contrib 
src/bin,installcheck)
+$(call recurse,installcheck-world,src/test src/pl src/interfaces/ecpg 
src/interfaces/libpq contrib src/bin,installcheck)
 $(call recurse,install-tests,src/test/regress,install-tests)
 
 GNUmakefile: GNUmakefile.in $(top_builddir)/config.status

Re: convert libpq uri-regress tests to tap test

[Andrew Dunstan]

On 2022-04-16 Sa 10:44, Justin Pryzby wrote:
> On Sat, Feb 26, 2022 at 05:46:26PM -0800, Andres Freund wrote:
>> Pushed.  Attached is the remainder, 0003, the move of libpq_pipeline to
>> src/interfaces/libpq that I'm not planning to push for now.
> I saw that Andrew just pushed something to start building this under MSVC.
>
> In case it's of any interest, I had done this differently a while back.
> This probably doesn't apply except on top of some other patches, but you get
> the idea.
>

I think what I have committed should be quite adequate for now. Once we
get to building with meson a lot of this ugliness should go away.


cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

Re: convert libpq uri-regress tests to tap test

[Justin Pryzby]

On Sat, Feb 26, 2022 at 05:46:26PM -0800, Andres Freund wrote:
> Pushed.  Attached is the remainder, 0003, the move of libpq_pipeline to
> src/interfaces/libpq that I'm not planning to push for now.

I saw that Andrew just pushed something to start building this under MSVC.

In case it's of any interest, I had done this differently a while back.
This probably doesn't apply except on top of some other patches, but you get
the idea.

commit 923f8a1c2cbea35cb01d1599caa2a81e3186181c
Author: Justin Pryzby 
Date:   Mon Feb 28 01:31:10 2022 -0600

f!

ci-os-only: windows

diff --git a/src/tools/msvc/Mkvcbuild.pm b/src/tools/msvc/Mkvcbuild.pm
index 4364ab943fd..71ec747e544 100644
--- a/src/tools/msvc/Mkvcbuild.pm
+++ b/src/tools/msvc/Mkvcbuild.pm
@@ -44,6 +44,7 @@ my $contrib_extraincludes  = {};
 my $contrib_extrasource= {
'uri-regress' => ['src/interfaces/libpq/test/uri-regress.c'],
'testclient' => ['src/interfaces/libpq/test/testclient.c'],
+   'libpq_pipeline' => ['src/interfaces/libpq/test/libpq_pipeline.c'],
 };
 my @contrib_excludes = (
'bool_plperl',  'commit_ts',
@@ -475,7 +476,7 @@ sub mkvcbuild
push @contrib_excludes, 'uuid-ossp';
}
 
-   foreach my $subdir ('contrib', 'src/test/modules', 
'src/interfaces/libpq')
+   foreach my $subdir ('contrib', 'src/test/modules') #, 
'src/interfaces/libpq')
{
opendir($D, $subdir) || croak "Could not opendir on $subdir!\n";
while (my $d = readdir($D))
@@ -804,6 +805,20 @@ sub mkvcbuild
$p->AddReference($postgres);
}
 
+   $mf = Project::read_file('src/interfaces/libpq/test/Makefile');
+   $mf =~ s{\\\r?\n}{}g;
+   $mf =~ m{PROGRAMS\s*=\s*(.*)$}m
+ || die 'Could not match in src/interfaces/libpq/test/Makefile' . "\n";
+   foreach my $prg (split /\s+/, $1)
+   {
+   my $proj = $solution->AddProject($prg, 'exe', 'bin');
+   $proj->AddFile("src/interfaces/libpq/test/$prg.c"); # implicit 
source file
+   $proj->AddIncludeDir('src/interfaces/libpq');
+   # XXX: pipeline needs pgcommon and ws2, but uri-regress doesn't
+   $proj->AddReference($libpq, $libpgport, $libpgcommon);
+   $proj->AddLibrary('ws2_32.lib');
+   }
+
$mf = Project::read_file('src/bin/scripts/Makefile');
$mf =~ s{\\\r?\n}{}g;
$mf =~ m{PROGRAMS\s*=\s*(.*)$}m

Re: convert libpq uri-regress tests to tap test

[Andres Freund]

Hi, 

On March 1, 2022 7:44:27 AM PST, Andrew Dunstan  wrote:
>
>On 2/24/22 07:19, Andrew Dunstan wrote:
>> On 2/23/22 20:52, Tom Lane wrote:
>>> Peter Eisentraut  writes:
 On 23.02.22 23:58, Tom Lane wrote:
> Peter Eisentraut  writes:
>> libpq TAP tests should be in src/interfaces/libpq/t/.
> That's failing to account for the fact that a libpq test can't
> really be a pure-perl TAP test; you need some C code to drive the
> library.
 Such things could be put under src/interfaces/libpq/test, or some other 
 subdirectory.  We already have src/interfaces/ecpg/test.
>>> OK, but then the TAP scripts are under src/interfaces/libpq/test/t,
>>> which isn't what you said.  I have no great objection to moving
>>> src/test/modules/libpq_pipeline/ to src/interfaces/libpq/test/,
>>> though, as long as the buildfarm will cope.
>>>
>>> 
>>
>> It won't without some adjustment.
>
>
>
>See
>
>and
>

Thanks! 
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: convert libpq uri-regress tests to tap test

[Andrew Dunstan]

On 2/24/22 07:19, Andrew Dunstan wrote:
> On 2/23/22 20:52, Tom Lane wrote:
>> Peter Eisentraut  writes:
>>> On 23.02.22 23:58, Tom Lane wrote:
 Peter Eisentraut  writes:
> libpq TAP tests should be in src/interfaces/libpq/t/.
 That's failing to account for the fact that a libpq test can't
 really be a pure-perl TAP test; you need some C code to drive the
 library.
>>> Such things could be put under src/interfaces/libpq/test, or some other 
>>> subdirectory.  We already have src/interfaces/ecpg/test.
>> OK, but then the TAP scripts are under src/interfaces/libpq/test/t,
>> which isn't what you said.  I have no great objection to moving
>> src/test/modules/libpq_pipeline/ to src/interfaces/libpq/test/,
>> though, as long as the buildfarm will cope.
>>
>>  
>
> It won't without some adjustment.



See

and



cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com

Re: convert libpq uri-regress tests to tap test

[Andres Freund]

Hi,

On 2022-02-25 17:52:29 -0800, Andres Freund wrote:
> I'd like to commit 0001 and 0002 soon, unless somebody sees a reason not to?

Pushed.  Attached is the remainder, 0003, the move of libpq_pipeline to
src/interfaces/libpq that I'm not planning to push for now.

Regards,

Andres
>From 61a89721c8aab3a1fd2300067c470807b4fe87bc Mon Sep 17 00:00:00 2001
From: Andres Freund 
Date: Thu, 24 Feb 2022 08:27:41 -0800
Subject: [PATCH v4] Move libpq_pipeline test into src/interfaces/libpq.

---
 .../libpq/t/002_pipeline.pl}  |  2 +-
 src/interfaces/libpq/test/.gitignore  |  1 +
 src/interfaces/libpq/test/Makefile|  2 +-
 .../libpq/test}/libpq_pipeline.c  |  0
 .../test}/traces/disallowed_in_pipeline.trace |  0
 .../libpq/test}/traces/multi_pipelines.trace  |  0
 .../libpq/test}/traces/nosync.trace   |  0
 .../libpq/test}/traces/pipeline_abort.trace   |  0
 .../libpq/test}/traces/prepared.trace |  0
 .../libpq/test}/traces/simple_pipeline.trace  |  0
 .../libpq/test}/traces/singlerow.trace|  0
 .../libpq/test}/traces/transaction.trace  |  0
 src/test/modules/Makefile |  1 -
 src/test/modules/libpq_pipeline/.gitignore|  5 
 src/test/modules/libpq_pipeline/Makefile  | 25 ---
 src/test/modules/libpq_pipeline/README|  1 -
 16 files changed, 3 insertions(+), 34 deletions(-)
 rename src/{test/modules/libpq_pipeline/t/001_libpq_pipeline.pl => interfaces/libpq/t/002_pipeline.pl} (96%)
 rename src/{test/modules/libpq_pipeline => interfaces/libpq/test}/libpq_pipeline.c (100%)
 rename src/{test/modules/libpq_pipeline => interfaces/libpq/test}/traces/disallowed_in_pipeline.trace (100%)
 rename src/{test/modules/libpq_pipeline => interfaces/libpq/test}/traces/multi_pipelines.trace (100%)
 rename src/{test/modules/libpq_pipeline => interfaces/libpq/test}/traces/nosync.trace (100%)
 rename src/{test/modules/libpq_pipeline => interfaces/libpq/test}/traces/pipeline_abort.trace (100%)
 rename src/{test/modules/libpq_pipeline => interfaces/libpq/test}/traces/prepared.trace (100%)
 rename src/{test/modules/libpq_pipeline => interfaces/libpq/test}/traces/simple_pipeline.trace (100%)
 rename src/{test/modules/libpq_pipeline => interfaces/libpq/test}/traces/singlerow.trace (100%)
 rename src/{test/modules/libpq_pipeline => interfaces/libpq/test}/traces/transaction.trace (100%)
 delete mode 100644 src/test/modules/libpq_pipeline/.gitignore
 delete mode 100644 src/test/modules/libpq_pipeline/Makefile
 delete mode 100644 src/test/modules/libpq_pipeline/README

diff --git a/src/test/modules/libpq_pipeline/t/001_libpq_pipeline.pl b/src/interfaces/libpq/t/002_pipeline.pl
similarity index 96%
rename from src/test/modules/libpq_pipeline/t/001_libpq_pipeline.pl
rename to src/interfaces/libpq/t/002_pipeline.pl
index 0c164dcaba5..2e288d8ba7c 100644
--- a/src/test/modules/libpq_pipeline/t/001_libpq_pipeline.pl
+++ b/src/interfaces/libpq/t/002_pipeline.pl
@@ -49,7 +49,7 @@ for my $testname (@tests)
 		my $expected;
 		my $result;
 
-		$expected = slurp_file_eval("traces/$testname.trace");
+		$expected = slurp_file_eval("test/traces/$testname.trace");
 		next unless $expected ne "";
 		$result = slurp_file_eval($traceout);
 		next unless $result ne "";
diff --git a/src/interfaces/libpq/test/.gitignore b/src/interfaces/libpq/test/.gitignore
index 5e803d8816a..e24d7f64dc3 100644
--- a/src/interfaces/libpq/test/.gitignore
+++ b/src/interfaces/libpq/test/.gitignore
@@ -1 +1,2 @@
 /uri-regress
+/libpq_pipeline
diff --git a/src/interfaces/libpq/test/Makefile b/src/interfaces/libpq/test/Makefile
index 54212159065..9f99309653f 100644
--- a/src/interfaces/libpq/test/Makefile
+++ b/src/interfaces/libpq/test/Makefile
@@ -11,7 +11,7 @@ endif
 override CPPFLAGS := -I$(libpq_srcdir) $(CPPFLAGS)
 LDFLAGS_INTERNAL += $(libpq_pgport)
 
-PROGS = uri-regress
+PROGS = uri-regress libpq_pipeline
 
 all: $(PROGS)
 
diff --git a/src/test/modules/libpq_pipeline/libpq_pipeline.c b/src/interfaces/libpq/test/libpq_pipeline.c
similarity index 100%
rename from src/test/modules/libpq_pipeline/libpq_pipeline.c
rename to src/interfaces/libpq/test/libpq_pipeline.c
diff --git a/src/test/modules/libpq_pipeline/traces/disallowed_in_pipeline.trace b/src/interfaces/libpq/test/traces/disallowed_in_pipeline.trace
similarity index 100%
rename from src/test/modules/libpq_pipeline/traces/disallowed_in_pipeline.trace
rename to src/interfaces/libpq/test/traces/disallowed_in_pipeline.trace
diff --git a/src/test/modules/libpq_pipeline/traces/multi_pipelines.trace b/src/interfaces/libpq/test/traces/multi_pipelines.trace
similarity index 100%
rename from src/test/modules/libpq_pipeline/traces/multi_pipelines.trace
rename to src/interfaces/libpq/test/traces/multi_pipelines.trace
diff --git a/src/test/modules/libpq_pipeline/traces/nosync.trace b/src/interfaces/libpq/test/traces/nosync.trace
similarity index 100%
rename from src/test/modules/libpq_pipeline/traces/nosync.

Re: convert libpq uri-regress tests to tap test

[Andres Freund]

Hi,

On 2022-02-25 09:56:47 -0800, Andres Freund wrote:
> On 2022-02-24 08:46:23 -0800, Andres Freund wrote:
> > I'm mildly inclined to only do 0001 and 0002 for now. We'd not loose msvc
> > coverage, because it already doesn't build the test. Once we've ironed that
> > stuff out, we could do 0003?
> 
> From what I can see in the buildfarm client, we'd not loose (nor gain) any
> buildfarm coverage either. It doesn't run the test today.

Attached are rebased patches. I polished 0001, the regress.pl -> 001_uri.pl
conversion some more (although some of perltidy's changes aren't clearly an
improvement).

I'd like to commit 0001 and 0002 soon, unless somebody sees a reason not to?

Greetings,

Andres Freund
>From 87017e4b0a78c486eca24aab96f32e1168c82b93 Mon Sep 17 00:00:00 2001
From: Andres Freund 
Date: Wed, 23 Feb 2022 12:22:56 -0800
Subject: [PATCH v3 1/3] Convert src/interfaces/libpq/test to a tap test.

The old form of the test needed a bunch of custom infrastructure. These days
tap tests provide the necessary infrastructure to do better.

We discussed whether to move this test to src/test/modules, alongside
libpq_pipeline, but concluded that the opposite direction would be
better. libpq_pipeline will be moved at a later date, once the buildfarm and
msvc build infrastructure is ready for it.

The invocation of the tap test will be added in the next commit. It involves
just enough buildsystem changes to be worth commiting separately. Can't happen
the other way round because prove errors out when invoked without tests.

Discussion: https://postgr.es/m/20220223203031.ezrd73ohvjgfk...@alap3.anarazel.de
---
 src/interfaces/libpq/t/001_uri.pl  | 244 +
 src/interfaces/libpq/test/.gitignore   |   2 -
 src/interfaces/libpq/test/Makefile |   7 +-
 src/interfaces/libpq/test/README   |   7 -
 src/interfaces/libpq/test/expected.out | 171 -
 src/interfaces/libpq/test/regress.in   |  57 --
 src/interfaces/libpq/test/regress.pl   |  65 ---
 7 files changed, 246 insertions(+), 307 deletions(-)
 create mode 100644 src/interfaces/libpq/t/001_uri.pl
 delete mode 100644 src/interfaces/libpq/test/README
 delete mode 100644 src/interfaces/libpq/test/expected.out
 delete mode 100644 src/interfaces/libpq/test/regress.in
 delete mode 100644 src/interfaces/libpq/test/regress.pl

diff --git a/src/interfaces/libpq/t/001_uri.pl b/src/interfaces/libpq/t/001_uri.pl
new file mode 100644
index 000..90f370f8fd6
--- /dev/null
+++ b/src/interfaces/libpq/t/001_uri.pl
@@ -0,0 +1,244 @@
+# Copyright (c) 2021-2022, PostgreSQL Global Development Group
+use strict;
+use warnings;
+
+use PostgreSQL::Test::Utils;
+use Test::More;
+use IPC::Run;
+
+
+# List of URIs tests. For each test the first element is the input string, the
+# second the expected stdout and the third the expected stderr.
+my @tests = (
+	[
+		q{postgresql://uri-user:secret@host:12345/db},
+		q{user='uri-user' password='secret' dbname='db' host='host' port='12345' (inet)},
+		q{},
+	],
+	[
+		q{postgresql://uri-user@host:12345/db},
+		q{user='uri-user' dbname='db' host='host' port='12345' (inet)}, q{},
+	],
+	[
+		q{postgresql://uri-user@host/db},
+		q{user='uri-user' dbname='db' host='host' (inet)}, q{},
+	],
+	[
+		q{postgresql://host:12345/db},
+		q{dbname='db' host='host' port='12345' (inet)}, q{},
+	],
+	[ q{postgresql://host/db}, q{dbname='db' host='host' (inet)}, q{}, ],
+	[
+		q{postgresql://uri-user@host:12345/},
+		q{user='uri-user' host='host' port='12345' (inet)},
+		q{},
+	],
+	[
+		q{postgresql://uri-user@host/},
+		q{user='uri-user' host='host' (inet)},
+		q{},
+	],
+	[ q{postgresql://uri-user@},   q{user='uri-user' (local)}, q{}, ],
+	[ q{postgresql://host:12345/}, q{host='host' port='12345' (inet)}, q{}, ],
+	[ q{postgresql://host:12345},  q{host='host' port='12345' (inet)}, q{}, ],
+	[ q{postgresql://host/db}, q{dbname='db' host='host' (inet)},  q{}, ],
+	[ q{postgresql://host/},   q{host='host' (inet)},  q{}, ],
+	[ q{postgresql://host},q{host='host' (inet)},  q{}, ],
+	[ q{postgresql://},q{(local)}, q{}, ],
+	[
+		q{postgresql://?hostaddr=127.0.0.1}, q{hostaddr='127.0.0.1' (inet)},
+		q{},
+	],
+	[
+		q{postgresql://example.com?hostaddr=63.1.2.4},
+		q{host='example.com' hostaddr='63.1.2.4' (inet)},
+		q{},
+	],
+	[ q{postgresql://%68ost/}, q{host='host' (inet)}, q{}, ],
+	[
+		q{postgresql://host/db?user=uri-user},
+		q{user='uri-user' dbname='db' host='host' (inet)},
+		q{},
+	],
+	[
+		q{postgresql://host/db?user=uri-user&port=12345},
+		q{user='uri-user' dbname='db' host='host' port='12345' (inet)},
+		q{},
+	],
+	[
+		q{postgresql://host/db?u%73er=someotheruser&port=12345},
+		q{user='someotheruser' dbname='db' host='host' port='12345' (inet)},
+		q{},
+	],
+	[
+		q{postgresql://host/db?u%7aer=someotheruser&port=12345}, q{},
+		q{uri-regress: invalid URI query parameter: "uzer"},
+	],
+	[
+		q{postgresql://h

Re: convert libpq uri-regress tests to tap test

[Andres Freund]

Hi,

On 2022-02-24 08:46:23 -0800, Andres Freund wrote:
> I'm mildly inclined to only do 0001 and 0002 for now. We'd not loose msvc
> coverage, because it already doesn't build the test. Once we've ironed that
> stuff out, we could do 0003?

>From what I can see in the buildfarm client, we'd not loose (nor gain) any
buildfarm coverage either. It doesn't run the test today.

Greetings,

Andres Freund

Re: convert libpq uri-regress tests to tap test

[Peter Eisentraut]

On 24.02.22 16:17, Tom Lane wrote:

I think that having t/ directories contain only Perl test scripts
is a good convention that we should stick to.  Peter's proposal
of a separate test/ subdirectory for C test scaffolding is
probably fine.


I wonder if there are any conventions in the Perl community about where 
to put test support files relative to the "t" directory.

Re: convert libpq uri-regress tests to tap test

[Andres Freund]

Hi,

On 2022-02-24 17:03:33 +, Jacob Champion wrote:
> On Thu, 2022-02-24 at 08:46 -0800, Andres Freund wrote:
> > One annoying bit is that our current tap invocation infrastructure for msvc
> > won't know how to deal with that. We put the build directory containing t/
> > onto PATH, but that won't work for test/. But we also don't want to install
> > test binaries. Not sure what the solution for that is.
> 
> Would it help if the C executable, not Perl, was the thing actually
> producing the TAP output? The binaries built from test/ could be placed
> into t/. Or does that just open up a new set of problems?

I don't think it would help that much. And for the libpq pipeline test it
doesn't really make sense anyway, because we intentionally use it with
different traces and such.

I've thought about a few C tap tests that I'd like, but I think that's a
separate discussion.

Greetings,

Andres Freund

Re: convert libpq uri-regress tests to tap test

[Jacob Champion]

On Thu, 2022-02-24 at 08:46 -0800, Andres Freund wrote:
> One annoying bit is that our current tap invocation infrastructure for msvc
> won't know how to deal with that. We put the build directory containing t/
> onto PATH, but that won't work for test/. But we also don't want to install
> test binaries. Not sure what the solution for that is.

Would it help if the C executable, not Perl, was the thing actually
producing the TAP output? The binaries built from test/ could be placed
into t/. Or does that just open up a new set of problems?

--Jacob

Re: convert libpq uri-regress tests to tap test

[Andres Freund]

Hi,

On 2022-02-24 10:17:28 -0500, Tom Lane wrote:
> Andres Freund  writes:
> > On 2022-02-24 13:31:40 +0100, Peter Eisentraut wrote:
> >> I think the TAP scripts should be in src/interfaces/libpq/t/, as usual. The
> >> supporting code snippets could live in some other directory under
> >> src/interfaces/libpq/, which might be called "test" or something else, not
> >> that important.
>
> > Why not in t/? We can't easily build the test programs in libpq/ itself, but
> > libpq/t should be fairly doable.
>
> I think that having t/ directories contain only Perl test scripts
> is a good convention that we should stick to.  Peter's proposal
> of a separate test/ subdirectory for C test scaffolding is
> probably fine.

That exists today and continues to exist in the patch upthread, so it's easy
;). I just need to move the libpq/test/t to libpq/t and adjust the binary
path.

One annoying bit is that our current tap invocation infrastructure for msvc
won't know how to deal with that. We put the build directory containing t/
onto PATH, but that won't work for test/. But we also don't want to install
test binaries. Not sure what the solution for that is.

Even on !windows, we only know how to find "test executables" in tap tests via
PATH. We're in the source dir, so we can't just do test/executable.

I probably just need another coffee, but right now I don't even see how to add
anything to PATH given $(prove_check)'s definition - it ends up with multiple
shells. We can fix that by using && in the definition, which might be a good
thing anyway?

Attached three patches:

0001: Convert src/interfaces/libpq/test to a tap test
0002: Add tap test infrastructure to src/interfaces/libpq
0003: Move libpq_pipeline test into src/interfaces/libpq.

I did 0001 and 0002 in that order because prove errors out with a stacktrace
if no tap tests exist... It might make more sense to commit them together, but
for review it's easier to keep them separate I think.


Andrew, do you have an idea about the feasibility of supporting any of this
with the msvc build?

I'm mildly inclined to only do 0001 and 0002 for now. We'd not loose msvc
coverage, because it already doesn't build the test. Once we've ironed that
stuff out, we could do 0003?

Greetings,

Andres Freund
>From 71fa1532a1540e8bbf8bdee3ec0b64e863f212f2 Mon Sep 17 00:00:00 2001
From: Andres Freund 
Date: Wed, 23 Feb 2022 12:22:56 -0800
Subject: [PATCH v2 1/3] Convert src/interfaces/libpq/test to a tap test.

The invocation of the tap test will be added in the next commit.
---
 src/interfaces/libpq/t/001_uri.pl  | 265 +
 src/interfaces/libpq/test/.gitignore   |   2 -
 src/interfaces/libpq/test/Makefile |   7 +-
 src/interfaces/libpq/test/README   |   7 -
 src/interfaces/libpq/test/expected.out | 171 
 src/interfaces/libpq/test/regress.in   |  57 --
 src/interfaces/libpq/test/regress.pl   |  65 --
 7 files changed, 267 insertions(+), 307 deletions(-)
 create mode 100644 src/interfaces/libpq/t/001_uri.pl
 delete mode 100644 src/interfaces/libpq/test/README
 delete mode 100644 src/interfaces/libpq/test/expected.out
 delete mode 100644 src/interfaces/libpq/test/regress.in
 delete mode 100644 src/interfaces/libpq/test/regress.pl

diff --git a/src/interfaces/libpq/t/001_uri.pl b/src/interfaces/libpq/t/001_uri.pl
new file mode 100644
index 000..0225666d9f6
--- /dev/null
+++ b/src/interfaces/libpq/t/001_uri.pl
@@ -0,0 +1,265 @@
+# Copyright (c) 2021-2022, PostgreSQL Global Development Group
+use strict;
+use warnings;
+
+use PostgreSQL::Test::Utils;
+use Test::More;
+use IPC::Run;
+
+my @tests = (
+	[q{postgresql://uri-user:secret@host:12345/db},
+	 q{user='uri-user' password='secret' dbname='db' host='host' port='12345' (inet)},
+ q{},
+],
+	[q{postgresql://uri-user@host:12345/db},
+	 q{user='uri-user' dbname='db' host='host' port='12345' (inet)},
+ q{},
+],
+	[q{postgresql://uri-user@host/db},
+	 q{user='uri-user' dbname='db' host='host' (inet)},
+ q{},
+],
+	[q{postgresql://host:12345/db},
+	 q{dbname='db' host='host' port='12345' (inet)},
+ q{},
+],
+	[q{postgresql://host/db},
+	 q{dbname='db' host='host' (inet)},
+ q{},
+],
+	[q{postgresql://uri-user@host:12345/},
+	 q{user='uri-user' host='host' port='12345' (inet)},
+ q{},
+],
+	[q{postgresql://uri-user@host/},
+	 q{user='uri-user' host='host' (inet)},
+ q{},
+],
+	[q{postgresql://uri-user@},
+	 q{user='uri-user' (local)},
+ q{},
+],
+	[q{postgresql://host:12345/},
+	 q{host='host' port='12345' (inet)},
+ q{},
+],
+	[q{postgresql://host:12345},
+	 q{host='host' port='12345' (inet)},
+ q{},
+],
+	[q{postgresql://host/db},
+	 q{dbname='db' host='host' (inet)},
+ q{},
+],
+	[q{postgresql://host/},
+	 q{host='host' (inet)},
+ q{},
+],
+	[q{postgresql://host},
+	 q{host='host' (inet)},
+ q{},
+],
+	[q{postgresql://},
+	 q{(local)},
+ q{},
+],
+	[q{postgresql://?

Re: convert libpq uri-regress tests to tap test

[Tom Lane]

Andres Freund  writes:
> On 2022-02-24 13:31:40 +0100, Peter Eisentraut wrote:
>> I think the TAP scripts should be in src/interfaces/libpq/t/, as usual. The
>> supporting code snippets could live in some other directory under
>> src/interfaces/libpq/, which might be called "test" or something else, not
>> that important.

> Why not in t/? We can't easily build the test programs in libpq/ itself, but
> libpq/t should be fairly doable.

I think that having t/ directories contain only Perl test scripts
is a good convention that we should stick to.  Peter's proposal
of a separate test/ subdirectory for C test scaffolding is
probably fine.

regards, tom lane

Re: convert libpq uri-regress tests to tap test

[Andres Freund]

Hi,

On 2022-02-24 13:31:40 +0100, Peter Eisentraut wrote:
> I think the TAP scripts should be in src/interfaces/libpq/t/, as usual. The
> supporting code snippets could live in some other directory under
> src/interfaces/libpq/, which might be called "test" or something else, not
> that important.

Why not in t/? We can't easily build the test programs in libpq/ itself, but
libpq/t should be fairly doable.

Greetings,

Andres Freund

Re: convert libpq uri-regress tests to tap test

[Peter Eisentraut]

On 24.02.22 02:52, Tom Lane wrote:

Peter Eisentraut  writes:

On 23.02.22 23:58, Tom Lane wrote:

Peter Eisentraut  writes:

libpq TAP tests should be in src/interfaces/libpq/t/.



That's failing to account for the fact that a libpq test can't
really be a pure-perl TAP test; you need some C code to drive the
library.



Such things could be put under src/interfaces/libpq/test, or some other
subdirectory.  We already have src/interfaces/ecpg/test.


OK, but then the TAP scripts are under src/interfaces/libpq/test/t,
which isn't what you said.  I have no great objection to moving
src/test/modules/libpq_pipeline/ to src/interfaces/libpq/test/,
though, as long as the buildfarm will cope.


I think the TAP scripts should be in src/interfaces/libpq/t/, as usual. 
The supporting code snippets could live in some other directory under 
src/interfaces/libpq/, which might be called "test" or something else, 
not that important.


I think we should pick a layout that is proper and future-proof and then 
adjust the buildfarm client as necessary.  The issue of writing 
libpq-specific tests has come up a few times recently; I think it would 
be worth finding a proper solution to this that would facilitate that 
work in the future.

Re: convert libpq uri-regress tests to tap test

[Andrew Dunstan]

On 2/23/22 20:52, Tom Lane wrote:
> Peter Eisentraut  writes:
>> On 23.02.22 23:58, Tom Lane wrote:
>>> Peter Eisentraut  writes:
 libpq TAP tests should be in src/interfaces/libpq/t/.
>>> That's failing to account for the fact that a libpq test can't
>>> really be a pure-perl TAP test; you need some C code to drive the
>>> library.
>> Such things could be put under src/interfaces/libpq/test, or some other 
>> subdirectory.  We already have src/interfaces/ecpg/test.
> OK, but then the TAP scripts are under src/interfaces/libpq/test/t,
> which isn't what you said.  I have no great objection to moving
> src/test/modules/libpq_pipeline/ to src/interfaces/libpq/test/,
> though, as long as the buildfarm will cope.
>
>   


It won't without some adjustment.


cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

Re: convert libpq uri-regress tests to tap test

[Tom Lane]

Peter Eisentraut  writes:
> On 23.02.22 23:58, Tom Lane wrote:
>> Peter Eisentraut  writes:
>>> libpq TAP tests should be in src/interfaces/libpq/t/.

>> That's failing to account for the fact that a libpq test can't
>> really be a pure-perl TAP test; you need some C code to drive the
>> library.

> Such things could be put under src/interfaces/libpq/test, or some other 
> subdirectory.  We already have src/interfaces/ecpg/test.

OK, but then the TAP scripts are under src/interfaces/libpq/test/t,
which isn't what you said.  I have no great objection to moving
src/test/modules/libpq_pipeline/ to src/interfaces/libpq/test/,
though, as long as the buildfarm will cope.

regards, tom lane

Re: convert libpq uri-regress tests to tap test

[Peter Eisentraut]

On 23.02.22 23:58, Tom Lane wrote:

Peter Eisentraut  writes:

On 23.02.22 21:30, Andres Freund wrote:

Where would we want that test to live? Right now we have the slightly odd
convention that some tap tests live in src/test/{misc,modules,...}. But
e.g. frontend binary ones are below src/bin/.



libpq TAP tests should be in src/interfaces/libpq/t/.



I think there were issues that the build farm wouldn't pick up a test
located there, but that should be fixed rather than worked around.


That's failing to account for the fact that a libpq test can't
really be a pure-perl TAP test; you need some C code to drive the
library.  I don't agree with intermixing such code with libpq
itself, independently of any buildsystem issues (which there
might well be).


Such things could be put under src/interfaces/libpq/test, or some other 
subdirectory.  We already have src/interfaces/ecpg/test.



So I think the design of putting such tests under
src/modules is fine.


I don't get what the rationale for that would be.  libpq tests are not 
"modules" of any kind.


If I'm working on libpq, I want to do make && make check inside the 
libpq source directory.

Re: convert libpq uri-regress tests to tap test

[Tom Lane]

Peter Eisentraut  writes:
> On 23.02.22 21:30, Andres Freund wrote:
>> Where would we want that test to live? Right now we have the slightly odd
>> convention that some tap tests live in src/test/{misc,modules,...}. But
>> e.g. frontend binary ones are below src/bin/.

> libpq TAP tests should be in src/interfaces/libpq/t/.

> I think there were issues that the build farm wouldn't pick up a test 
> located there, but that should be fixed rather than worked around.

That's failing to account for the fact that a libpq test can't
really be a pure-perl TAP test; you need some C code to drive the
library.  I don't agree with intermixing such code with libpq
itself, independently of any buildsystem issues (which there
might well be).  So I think the design of putting such tests under
src/modules is fine.

regards, tom lane

Re: convert libpq uri-regress tests to tap test

[Peter Eisentraut]

On 23.02.22 21:30, Andres Freund wrote:

hen verifying that the meson port actually runs all perl based tests I came
across src/interfaces/libpq/test/regress.pl.  Instead of running tests yet
another way, it seems better to convert it to a tap test.

I hope others agree?

Where would we want that test to live? Right now we have the slightly odd
convention that some tap tests live in src/test/{misc,modules,...}. But
e.g. frontend binary ones are below src/bin/.


libpq TAP tests should be in src/interfaces/libpq/t/.

I think there were issues that the build farm wouldn't pick up a test 
located there, but that should be fixed rather than worked around.

Re: convert libpq uri-regress tests to tap test

[Tom Lane]

Alvaro Herrera  writes:
> On 2022-Feb-23, Andres Freund wrote:
>> Separately: I don't really understand why we do the whole if USE_PGXS dance 
>> in
>> src/test/modules?

> Yeah, it seems a bit silly.  I'm not opposed to making these makefiles
> unconditionally do the PGXS thing -- or the non-PGXS thing, if that
> makes it easier to build multiple binaries.

Agreed, we could easily lose that.  I think we only do it in contrib
to serve as an example of how to use PGXS ... although considering
we're not *testing* that build mode, one wonders how much that proves.
In any case, src/test/modules doesn't have to do it.

regards, tom lane

Re: convert libpq uri-regress tests to tap test

[Andrew Dunstan]

On 2/23/22 16:16, Andres Freund wrote:
> Hi,
>
> On 2022-02-23 15:57:08 -0500, Tom Lane wrote:
>> Andrew Dunstan  writes:
>>> On 2/23/22 15:30, Andres Freund wrote:
 Perhaps we should just rename src/test/modules/libpq_pipeline to
 src/test/modules/libpq and move uri-regress in there as well?
>>> WFM
>> +1
> Cool.
>
>
> One question on making that happen: Right now the makefiles building C stuff
> in src/test/modules all have the contrib-style stanza to build via pgxs.  But
> afaics pgxs doesn't support building multiple programs. Which
> src/test/modules/libpq would need to.


That's my understanding also.


>
> Aaics there's currently no way to have Mkvcbuild.pm build multiple programs in
> one dir via its makefile parsing stuff? Andrew, any suggestions for not
> needing to spell this out in both the makefile and Mkvcbuild.pm?


Well, it should be a SMOC. If you can solve the first problem I'm sure I
can come up with a solution for Mkvcbuild.pm. But until we see the shape
of the pgxs changes, planning for Mkcvbuild.pm changes seems remature.


>
>
> Separately: I don't really understand why we do the whole if USE_PGXS dance in
> src/test/modules?
>

ENOCLUE


cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com

Re: convert libpq uri-regress tests to tap test

[Alvaro Herrera]

On 2022-Feb-23, Andres Freund wrote:

> Separately: I don't really understand why we do the whole if USE_PGXS dance in
> src/test/modules?

Yeah, it seems a bit silly.  I'm not opposed to making these makefiles
unconditionally do the PGXS thing -- or the non-PGXS thing, if that
makes it easier to build multiple binaries.

-- 
Álvaro Herrera  Valdivia, Chile  —  https://www.EnterpriseDB.com/
"La grandeza es una experiencia transitoria.  Nunca es consistente.
Depende en gran parte de la imaginación humana creadora de mitos"
(Irulan)

Re: convert libpq uri-regress tests to tap test

[Alvaro Herrera]

On 2022-Feb-23, Andres Freund wrote:

> When verifying that the meson port actually runs all perl based tests I came
> across src/interfaces/libpq/test/regress.pl.  Instead of running tests yet
> another way, it seems better to convert it to a tap test.
> 
> I hope others agree?

WFM.

> Perhaps we should just rename src/test/modules/libpq_pipeline to
> src/test/modules/libpq and move uri-regress in there as well?

Well, building multiple binaries would require some trickery that might
be excessive for this little tool.  But +1 to that on principle.

-- 
Álvaro Herrera  Valdivia, Chile  —  https://www.EnterpriseDB.com/
"La virtud es el justo medio entre dos defectos" (Aristóteles)

Re: convert libpq uri-regress tests to tap test

[Andres Freund]

Hi,

On 2022-02-23 15:57:08 -0500, Tom Lane wrote:
> Andrew Dunstan  writes:
> > On 2/23/22 15:30, Andres Freund wrote:
> >> Perhaps we should just rename src/test/modules/libpq_pipeline to
> >> src/test/modules/libpq and move uri-regress in there as well?
> 
> > WFM
> 
> +1

Cool.


One question on making that happen: Right now the makefiles building C stuff
in src/test/modules all have the contrib-style stanza to build via pgxs.  But
afaics pgxs doesn't support building multiple programs. Which
src/test/modules/libpq would need to.

Aaics there's currently no way to have Mkvcbuild.pm build multiple programs in
one dir via its makefile parsing stuff? Andrew, any suggestions for not
needing to spell this out in both the makefile and Mkvcbuild.pm?


Separately: I don't really understand why we do the whole if USE_PGXS dance in
src/test/modules?

- Andres

Re: convert libpq uri-regress tests to tap test

[Tom Lane]

Andrew Dunstan  writes:
> On 2/23/22 15:30, Andres Freund wrote:
>> Perhaps we should just rename src/test/modules/libpq_pipeline to
>> src/test/modules/libpq and move uri-regress in there as well?

> WFM

+1

regards, tom lane

Re: convert libpq uri-regress tests to tap test

[Daniel Gustafsson]

> On 23 Feb 2022, at 21:30, Andres Freund  wrote:

> When verifying that the meson port actually runs all perl based tests I came
> across src/interfaces/libpq/test/regress.pl.  Instead of running tests yet
> another way, it seems better to convert it to a tap test.
> 
> I hope others agree?

Many +1's on that.

> The tap test needs a bit more polish, mostly posted this to get some feedback
> before wasting more time :)

Skimming the new test it seems structurally fine to me.

--
Daniel Gustafsson   https://vmware.com/

Re: convert libpq uri-regress tests to tap test

[Andrew Dunstan]

On 2/23/22 15:30, Andres Freund wrote:
> Hi,
>
> When verifying that the meson port actually runs all perl based tests I came
> across src/interfaces/libpq/test/regress.pl.  Instead of running tests yet
> another way, it seems better to convert it to a tap test.
>
> I hope others agree?


yes


>
> Where would we want that test to live? Right now we have the slightly odd
> convention that some tap tests live in src/test/{misc,modules,...}. But
> e.g. frontend binary ones are below src/bin/.
>
> For now I've left it in src/interfaces/libpq/test, with the test in
> t/001_uri.pl. But we should at least get rid of the test/...
>
> Perhaps we should just rename src/test/modules/libpq_pipeline to
> src/test/modules/libpq and move uri-regress in there as well?



WFM


cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com

convert libpq uri-regress tests to tap test

[Andres Freund]

Hi,

When verifying that the meson port actually runs all perl based tests I came
across src/interfaces/libpq/test/regress.pl.  Instead of running tests yet
another way, it seems better to convert it to a tap test.

I hope others agree?

Where would we want that test to live? Right now we have the slightly odd
convention that some tap tests live in src/test/{misc,modules,...}. But
e.g. frontend binary ones are below src/bin/.

For now I've left it in src/interfaces/libpq/test, with the test in
t/001_uri.pl. But we should at least get rid of the test/...

Perhaps we should just rename src/test/modules/libpq_pipeline to
src/test/modules/libpq and move uri-regress in there as well?


The tap test needs a bit more polish, mostly posted this to get some feedback
before wasting more time :)

Greetings,

Andres Freund
>From 77b3666c9a7f17f98120cfc9c2a8e99f7d4ab491 Mon Sep 17 00:00:00 2001
From: Andres Freund 
Date: Wed, 23 Feb 2022 12:22:56 -0800
Subject: [PATCH v1] Convert src/interfaces/libpq/test to a tap test.

---
 src/interfaces/libpq/Makefile  |   2 +-
 src/interfaces/libpq/test/Makefile |  10 +-
 src/interfaces/libpq/test/README   |   7 -
 src/interfaces/libpq/test/expected.out | 171 
 src/interfaces/libpq/test/regress.in   |  57 --
 src/interfaces/libpq/test/regress.pl   |  65 --
 src/interfaces/libpq/test/t/001_uri.pl | 266 +
 7 files changed, 274 insertions(+), 304 deletions(-)
 delete mode 100644 src/interfaces/libpq/test/README
 delete mode 100644 src/interfaces/libpq/test/expected.out
 delete mode 100644 src/interfaces/libpq/test/regress.in
 delete mode 100644 src/interfaces/libpq/test/regress.pl
 create mode 100644 src/interfaces/libpq/test/t/001_uri.pl

diff --git a/src/interfaces/libpq/Makefile b/src/interfaces/libpq/Makefile
index 844c95d47de..8920f7e6365 100644
--- a/src/interfaces/libpq/Makefile
+++ b/src/interfaces/libpq/Makefile
@@ -137,7 +137,7 @@ install: all installdirs install-lib
 	$(INSTALL_DATA) $(srcdir)/pqexpbuffer.h '$(DESTDIR)$(includedir_internal)'
 	$(INSTALL_DATA) $(srcdir)/pg_service.conf.sample '$(DESTDIR)$(datadir)/pg_service.conf.sample'
 
-installcheck:
+installcheck check:
 	$(MAKE) -C test $@
 
 installdirs: installdirs-lib
diff --git a/src/interfaces/libpq/test/Makefile b/src/interfaces/libpq/test/Makefile
index 4832fab9d23..5dbfe5d09ae 100644
--- a/src/interfaces/libpq/test/Makefile
+++ b/src/interfaces/libpq/test/Makefile
@@ -1,3 +1,5 @@
+# src/interfaces/libpq/test/Makefile
+
 subdir = src/interfaces/libpq/test
 top_builddir = ../../../..
 include $(top_builddir)/src/Makefile.global
@@ -13,10 +15,12 @@ PROGS = uri-regress
 
 all: $(PROGS)
 
+check: all
+	$(prove_check)
+
 installcheck: all
-	SRCDIR='$(top_srcdir)' SUBDIR='$(subdir)' \
-		   $(PERL) $(top_srcdir)/$(subdir)/regress.pl
+	$(prove_installcheck)
 
 clean distclean maintainer-clean:
 	rm -f $(PROGS) *.o
-	rm -f regress.out regress.diff
+	rm -rf tmp_check
diff --git a/src/interfaces/libpq/test/README b/src/interfaces/libpq/test/README
deleted file mode 100644
index a05eb6bb3bc..000
--- a/src/interfaces/libpq/test/README
+++ /dev/null
@@ -1,7 +0,0 @@
-This is a testsuite for testing libpq URI connection string syntax.
-
-To run the suite, use 'make installcheck' command.  It works by
-running 'regress.pl' from this directory with appropriate environment
-set up, which in turn feeds up lines from 'regress.in' to
-'uri-regress' test program and compares the output against the correct
-one in 'expected.out' file.
diff --git a/src/interfaces/libpq/test/expected.out b/src/interfaces/libpq/test/expected.out
deleted file mode 100644
index d375e82b4ac..000
--- a/src/interfaces/libpq/test/expected.out
+++ /dev/null
@@ -1,171 +0,0 @@
-trying postgresql://uri-user:secret@host:12345/db
-user='uri-user' password='secret' dbname='db' host='host' port='12345' (inet)
-
-trying postgresql://uri-user@host:12345/db
-user='uri-user' dbname='db' host='host' port='12345' (inet)
-
-trying postgresql://uri-user@host/db
-user='uri-user' dbname='db' host='host' (inet)
-
-trying postgresql://host:12345/db
-dbname='db' host='host' port='12345' (inet)
-
-trying postgresql://host/db
-dbname='db' host='host' (inet)
-
-trying postgresql://uri-user@host:12345/
-user='uri-user' host='host' port='12345' (inet)
-
-trying postgresql://uri-user@host/
-user='uri-user' host='host' (inet)
-
-trying postgresql://uri-user@
-user='uri-user' (local)
-
-trying postgresql://host:12345/
-host='host' port='12345' (inet)
-
-trying postgresql://host:12345
-host='host' port='12345' (inet)
-
-trying postgresql://host/db
-dbname='db' host='host' (inet)
-
-trying postgresql://host/
-host='host' (inet)
-
-trying postgresql://host
-host='host' (inet)
-
-trying postgresql://
-(local)
-
-trying postgresql://?hostaddr=127.0.0.1
-hostaddr='127.0.0.1' (inet)
-
-trying postgresql://example.com?hostaddr=63.1.2.4
-host='example.com' hostaddr='63.1.2.4' (inet)
-
-trying postgresql://%68ost/
-hos