Re: Allow auto_explain to log to NOTICE - Mailing list pgsql-hackers

From Daniel Gustafsson
Subject Re: Allow auto_explain to log to NOTICE
Date
Msg-id EEA234AC-85E2-4173-8433-CC673AE4007A@yesql.se
Whole thread Raw
In response to Re: Allow auto_explain to log to NOTICE  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Allow auto_explain to log to NOTICE  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
(Michael: sorry for not having responded to your comments on the patch, $life
has had little time over for hacking lately)

> On 4 Jan 2019, at 13:49, Michael Paquier <michael@paquier.xyz> wrote:
>
> On Fri, Jan 04, 2019 at 01:06:24PM +0100, Peter Eisentraut wrote:
>> Do we really want to add user-facing options just to be able to run
>> tests?  Should we write the tests differently instead?

I voiced this concern upthread as well, not being sure if it’s worth the added
complexity.

> The take is that the output of the plans generated includes data which
> is run-dependent because the duration of the plan is generated
> unconditionally.  One way to write generic tests considering this
> would be to use a TAP test, but I feel that's overdoing it just for
> this case.
>
> Being able to control if the plan duration shows up still looks like
> an interesting option to me independently of adding tests.

There is that.  We might not be excited about writing tests for this contrib
module but someone else might want to use this for testing their application in
a similar manner to how pg_regress tests?

cheers ./daniel

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [PATCH] Pass COPT and PROFILE to CXXFLAGS as well
Next
From: Pavel Stehule
Date:
Subject: Re: proposal - plpgsql unique statement id