Re: Hide 'Execution time' in EXPLAIN (COSTS OFF) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Hide 'Execution time' in EXPLAIN (COSTS OFF)
Date
Msg-id 15161.1413592762@sss.pgh.pa.us
Whole thread Raw
In response to Re: Hide 'Execution time' in EXPLAIN (COSTS OFF)  (David Rowley <dgrowleyml@gmail.com>)
Responses Re: Hide 'Execution time' in EXPLAIN (COSTS OFF)
List pgsql-hackers
David Rowley <dgrowleyml@gmail.com> writes:
> On Fri, Oct 17, 2014 at 3:34 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I don't want to go there.  It would be a lot better to expend the effort
>> on a better regression testing infrastructure that wouldn't *need*
>> bitwise-identical output across platforms.  (mysql is ahead of us in that
>> department: they have some hacks for selective matching of the output.)

> Perhaps we could introduce some sort of wildcard matching in the regression
> tests. So that we could stick something like:
>  Execution time: * ms
> Into the expected results, though, probably we'd need to come up with some
> wildcard character which is a bit less common than *

I was imagining that we might as well allow regexp matching, so you could
be as specific as
  Execution time: \d+\.\d+ ms

if you had a mind to.  But with or without that, it would be difficult to
pick a meta-character that never appears in expected-output files today.
What we'd probably want to do (again, I'm stealing ideas from what I
remember of the mysql regression tests) is add metasyntax to switch
between literal and wildcard/regexp matching.  So perhaps an expected
file could contain something like

-- !!match regexp
... expected output including regexps ...
-- !!match literal
... normal expected output here

Not sure how we get there without writing our own diff engine though :-(.
        regards, tom lane



pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Hide 'Execution time' in EXPLAIN (COSTS OFF)
Next
From: Feng Tian
Date:
Subject: Re: Optimizer on sort aggregate