Thread: Ignoring white space in regression tests really a good idea?
pg_regress compares expected and actual output using "diff -w" (a/k/a --ignore-all-space). We have always done this, and I think the idea was to avoid getting a lot of useless diff noise when the only real difference is that one column value in a tabular display is wider than expected. I'm wondering if it's such a good idea though. I just noticed that -w was masking a couple of recent changes in the regression outputs, notably this one in create_cast: SELECT 1234::int4::casttesttype; -- No cast yet, should fail ERROR: cannot cast type integer to casttesttype LINE 1: SELECT1234::int4::casttesttype; ! ^ CREATE CAST (int4 AS casttesttype) WITH INOUT; SELECT 1234::int4::casttesttype; -- Should work now casttesttype --- 53,59 ---- SELECT 1234::int4::casttesttype; -- No cast yet, should fail ERROR: cannot cast type integer to casttesttypeLINE 1: SELECT 1234::int4::casttesttype; ! ^ CREATE CAST (int4 AS casttesttype) WITH INOUT; SELECT 1234::int4::casttesttype; -- Should worknow casttesttype If one supposes that one part of what this test is doing is checking which part of the construct is pointed to by the error cursor, then using -w in the check renders it useless. I'm thinking maybe we should remove -w. Comments? regards, tom lane
On Nov 22, 2009, at 7:49 AM, Tom Lane wrote: > I'm thinking maybe we should remove -w. Comments? Have you tried it on the existing tests to see what happens? David
On Sat, Nov 21, 2009 at 16:07, David E. Wheeler <david@kineticode.com> wrote: > On Nov 22, 2009, at 7:49 AM, Tom Lane wrote: > >> I'm thinking maybe we should remove -w. Comments? > > Have you tried it on the existing tests to see what happens? For me there I get: *the breaking in create_cast *various things in foreign_key due to the tests not having spaces after commas i.e: ! DETAIL: Key (ftest1,ftest2)=(2,2) is not present in table "pktable". ! DETAIL: Key (ftest1, ftest2)=(100, 2) is not present in table "pktable". * exta space after a " ! CONTEXT: SQL statement "SELECT 1/ $1 " ! CONTEXT: SQL statement "SELECT 1/$1" All those things are easily fixable so it seems worth it to me +1