Latest Data::Dumper breaks hstore_plperl regression test
Or at least, that's what I surmise from the fact that buildfarm critter
caiman has been failing that test for the last day or so, with symptoms
indicating whitespace changes in Data::Dumper output. Some poking into
the Fedora repo shows that rawhide updated perl-Data-Dumper from 2.161
to 2.167 on May 11, so that fits ...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sat, May 13, 2017 at 6:22 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Or at least, that's what I surmise from the fact that buildfarm critter
caiman has been failing that test for the last day or so, with symptoms
indicating whitespace changes in Data::Dumper output. Some poking into
the Fedora repo shows that rawhide updated perl-Data-Dumper from 2.161
to 2.167 on May 11, so that fits ...
Depending on the precise details of how Data::Dumper prints things
doesn't seem like a particularly good idea.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 14 May 2017 11:33, "Robert Haas" <robertmhaas@gmail.com> wrote:
On Sat, May 13, 2017 at 6:22 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Or at least, that's what I surmise from the fact that buildfarm critter
caiman has been failing that test for the last day or so, with symptoms
indicating whitespace changes in Data::Dumper output. Some poking into
the Fedora repo shows that rawhide updated perl-Data-Dumper from 2.161
to 2.167 on May 11, so that fits ...
Depending on the precise details of how Data::Dumper prints things
doesn't seem like a particularly good idea.
Surely Test::More::is_deeply is the way to go here.
On 05/13/2017 11:43 PM, Craig Ringer wrote:
On 14 May 2017 11:33, "Robert Haas" <robertmhaas@gmail.com
<mailto:robertmhaas@gmail.com>> wrote:On Sat, May 13, 2017 at 6:22 PM, Tom Lane <tgl@sss.pgh.pa.us
<mailto:tgl@sss.pgh.pa.us>> wrote:Or at least, that's what I surmise from the fact that buildfarm
critter
caiman has been failing that test for the last day or so, with
symptoms
indicating whitespace changes in Data::Dumper output. Some
poking into
the Fedora repo shows that rawhide updated perl-Data-Dumper from
2.161
to 2.167 on May 11, so that fits ...
Depending on the precise details of how Data::Dumper prints things
doesn't seem like a particularly good idea.Surely Test::More::is_deeply is the way to go here.
This isn't a TAP test. It's a standard pg_regress test.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 05/13/2017 11:32 PM, Robert Haas wrote:
On Sat, May 13, 2017 at 6:22 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Or at least, that's what I surmise from the fact that buildfarm critter
caiman has been failing that test for the last day or so, with symptoms
indicating whitespace changes in Data::Dumper output. Some poking into
the Fedora repo shows that rawhide updated perl-Data-Dumper from 2.161
to 2.167 on May 11, so that fits ...Depending on the precise details of how Data::Dumper prints things
doesn't seem like a particularly good idea.
I'd be inclined to set $Data::Dumper::Indent to 0 which would suppress
all indentation, and adjusting the test results accordingly. We already
set $Data::Dumper::Sortkeys to 1, so there's precedent for controlling
how it presents data back to us.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
On 05/13/2017 11:32 PM, Robert Haas wrote:
Depending on the precise details of how Data::Dumper prints things
doesn't seem like a particularly good idea.
I'd be inclined to set $Data::Dumper::Indent to 0 which would suppress
all indentation, and adjusting the test results accordingly. We already
set $Data::Dumper::Sortkeys to 1, so there's precedent for controlling
how it presents data back to us.
Sounds plausible to me.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 05/14/2017 12:04 AM, Andrew Dunstan wrote:
On 05/13/2017 11:32 PM, Robert Haas wrote:
On Sat, May 13, 2017 at 6:22 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Or at least, that's what I surmise from the fact that buildfarm critter
caiman has been failing that test for the last day or so, with symptoms
indicating whitespace changes in Data::Dumper output. Some poking into
the Fedora repo shows that rawhide updated perl-Data-Dumper from 2.161
to 2.167 on May 11, so that fits ...Depending on the precise details of how Data::Dumper prints things
doesn't seem like a particularly good idea.I'd be inclined to set $Data::Dumper::Indent to 0 which would suppress
all indentation, and adjusting the test results accordingly. We already
set $Data::Dumper::Sortkeys to 1, so there's precedent for controlling
how it presents data back to us.
Here's a patch along those lines.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachments:
hstore-plperl-data-dumper-fix.patchtext/x-patch; name=hstore-plperl-data-dumper-fix.patchDownload
diff --git a/contrib/hstore_plperl/expected/hstore_plperlu.out b/contrib/hstore_plperl/expected/hstore_plperlu.out
index b09fb78..d719d29 100644
--- a/contrib/hstore_plperl/expected/hstore_plperlu.out
+++ b/contrib/hstore_plperl/expected/hstore_plperlu.out
@@ -20,15 +20,12 @@ TRANSFORM FOR TYPE hstore
AS $$
use Data::Dumper;
$Data::Dumper::Sortkeys = 1;
+$Data::Dumper::Indent = 0;
elog(INFO, Dumper($_[0]));
return scalar(keys %{$_[0]});
$$;
SELECT test1('aa=>bb, cc=>NULL'::hstore);
-INFO: $VAR1 = {
- 'aa' => 'bb',
- 'cc' => undef
- };
-
+INFO: $VAR1 = {'aa' => 'bb','cc' => undef};
test1
-------
2
@@ -39,12 +36,12 @@ LANGUAGE plperlu
AS $$
use Data::Dumper;
$Data::Dumper::Sortkeys = 1;
+$Data::Dumper::Indent = 0;
elog(INFO, Dumper($_[0]));
return scalar(keys %{$_[0]});
$$;
SELECT test1none('aa=>bb, cc=>NULL'::hstore);
INFO: $VAR1 = '"aa"=>"bb", "cc"=>NULL';
-
test1none
-----------
0
@@ -56,15 +53,12 @@ TRANSFORM FOR TYPE hstore
AS $$
use Data::Dumper;
$Data::Dumper::Sortkeys = 1;
+$Data::Dumper::Indent = 0;
elog(INFO, Dumper($_[0]));
return scalar(keys %{$_[0]});
$$;
SELECT test1list('aa=>bb, cc=>NULL'::hstore);
-INFO: $VAR1 = {
- 'aa' => 'bb',
- 'cc' => undef
- };
-
+INFO: $VAR1 = {'aa' => 'bb','cc' => undef};
test1list
-----------
2
@@ -77,18 +71,12 @@ TRANSFORM FOR TYPE hstore
AS $$
use Data::Dumper;
$Data::Dumper::Sortkeys = 1;
+$Data::Dumper::Indent = 0;
elog(INFO, Dumper($_[0]->[0], $_[0]->[1]));
return scalar(keys %{$_[0]});
$$;
SELECT test1arr(array['aa=>bb, cc=>NULL'::hstore, 'dd=>ee']);
-INFO: $VAR1 = {
- 'aa' => 'bb',
- 'cc' => undef
- };
-$VAR2 = {
- 'dd' => 'ee'
- };
-
+INFO: $VAR1 = {'aa' => 'bb','cc' => undef};$VAR2 = {'dd' => 'ee'};
test1arr
----------
2
@@ -101,6 +89,7 @@ TRANSFORM FOR TYPE hstore
AS $$
use Data::Dumper;
$Data::Dumper::Sortkeys = 1;
+$Data::Dumper::Indent = 0;
$rv = spi_exec_query(q{SELECT 'aa=>bb, cc=>NULL'::hstore AS col1});
elog(INFO, Dumper($rv->{rows}[0]->{col1}));
@@ -111,13 +100,8 @@ $rv = spi_exec_prepared($plan, {}, $val);
elog(INFO, Dumper($rv->{rows}[0]->{col1}));
$$;
SELECT test3();
-INFO: $VAR1 = {
- 'aa' => 'bb',
- 'cc' => undef
- };
-
+INFO: $VAR1 = {'aa' => 'bb','cc' => undef};
INFO: $VAR1 = '"a"=>"1", "b"=>"boo", "c"=>NULL';
-
test3
-------
@@ -138,6 +122,7 @@ TRANSFORM FOR TYPE hstore
AS $$
use Data::Dumper;
$Data::Dumper::Sortkeys = 1;
+$Data::Dumper::Indent = 0;
elog(INFO, Dumper($_TD->{new}));
if ($_TD->{new}{a} == 1) {
$_TD->{new}{b} = {a => 1, b => 'boo', c => undef};
@@ -147,14 +132,7 @@ return "MODIFY";
$$;
CREATE TRIGGER test4 BEFORE UPDATE ON test1 FOR EACH ROW EXECUTE PROCEDURE test4();
UPDATE test1 SET a = a;
-INFO: $VAR1 = {
- 'a' => '1',
- 'b' => {
- 'aa' => 'bb',
- 'cc' => undef
- }
- };
-
+INFO: $VAR1 = {'a' => '1','b' => {'aa' => 'bb','cc' => undef}};
SELECT * FROM test1;
a | b
---+---------------------------------
diff --git a/contrib/hstore_plperl/sql/hstore_plperlu.sql b/contrib/hstore_plperl/sql/hstore_plperlu.sql
index 8d8508c..c714b35 100644
--- a/contrib/hstore_plperl/sql/hstore_plperlu.sql
+++ b/contrib/hstore_plperl/sql/hstore_plperlu.sql
@@ -15,6 +15,7 @@ TRANSFORM FOR TYPE hstore
AS $$
use Data::Dumper;
$Data::Dumper::Sortkeys = 1;
+$Data::Dumper::Indent = 0;
elog(INFO, Dumper($_[0]));
return scalar(keys %{$_[0]});
$$;
@@ -26,6 +27,7 @@ LANGUAGE plperlu
AS $$
use Data::Dumper;
$Data::Dumper::Sortkeys = 1;
+$Data::Dumper::Indent = 0;
elog(INFO, Dumper($_[0]));
return scalar(keys %{$_[0]});
$$;
@@ -38,6 +40,7 @@ TRANSFORM FOR TYPE hstore
AS $$
use Data::Dumper;
$Data::Dumper::Sortkeys = 1;
+$Data::Dumper::Indent = 0;
elog(INFO, Dumper($_[0]));
return scalar(keys %{$_[0]});
$$;
@@ -52,6 +55,7 @@ TRANSFORM FOR TYPE hstore
AS $$
use Data::Dumper;
$Data::Dumper::Sortkeys = 1;
+$Data::Dumper::Indent = 0;
elog(INFO, Dumper($_[0]->[0], $_[0]->[1]));
return scalar(keys %{$_[0]});
$$;
@@ -66,6 +70,7 @@ TRANSFORM FOR TYPE hstore
AS $$
use Data::Dumper;
$Data::Dumper::Sortkeys = 1;
+$Data::Dumper::Indent = 0;
$rv = spi_exec_query(q{SELECT 'aa=>bb, cc=>NULL'::hstore AS col1});
elog(INFO, Dumper($rv->{rows}[0]->{col1}));
@@ -90,6 +95,7 @@ TRANSFORM FOR TYPE hstore
AS $$
use Data::Dumper;
$Data::Dumper::Sortkeys = 1;
+$Data::Dumper::Indent = 0;
elog(INFO, Dumper($_TD->{new}));
if ($_TD->{new}{a} == 1) {
$_TD->{new}{b} = {a => 1, b => 'boo', c => undef};
Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
Here's a patch along those lines.
Looks sane in a quick once-over. Note this needs to be back-patched.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers