From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Subject: Re: Regression tests vs existing users in an installation
Date: Mon, 18 Jul 2016 11:13:02 -0400
Message-ID: <23690.1468854782@sss.pgh.pa.us> (raw)
In-Reply-To: <CA+TgmoZf-TodYQJz91bLm8WLsEefNhdJJfM1wn+AnYehadDwoA@mail.gmail.com>
References: <20160716035456.GA181422@alvherre.pgsql>
<25245.1468683514@sss.pgh.pa.us>
<CA+TgmoZf-TodYQJz91bLm8WLsEefNhdJJfM1wn+AnYehadDwoA@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
Robert Haas <robertmhaas@gmail.com> writes:
> On Sat, Jul 16, 2016 at 11:38 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I'm coming to the conclusion that the only thing that will make this
>> materially better in the long run is automatic enforcement of a convention
>> about what role names may be created in the regression tests. See my
>> response to Stephen just now for a concrete proposal.
> We could also do this by loading a C module during the regression
> tests, which seems maybe less ugly than adding a GUC.
Meh, I'm not convinced. As Michael points out, arranging for such a
module to get loaded in an installcheck context would be difficult ---
maybe not impossible, but complicated. Also, we'd have to add hook
function calls in all the places it would need to get control; most
of those places would probably be one-off hooks with no other conceivable
use. And we'd still need to have a GUC, because I think it's inevitable
that we'd need to be able to turn off the restrictions for specific
tests. So that seems like a lot of work and complication just to make
a GUC be custom to some undocumented extension rather than built-in.
If we had no other debugging GUCs then there might be some point in
rejecting this one, but we have a bunch:
https://www.postgresql.org/docs/devel/static/runtime-config-developer.html> I don't particularly like your suggestion of spooky action at a
> distance between force_parallel_mode and regression_test_mode. That
> just seems kooky.
It's certainly a judgment call as to which way is cleaner, but I don't
understand your objection. There are plenty of ways in which multiple
GUCs determine a given behavior already. Also, breaking this behavior
into two variables would let us document the user-useful behavior (do
this to test parallel safety of functions) in a different place from the
developer-useful behavior (do this to make EXPLAIN lie to you, which
surely has no possible use except for regression testing).
Possibly a single "regression_test_mode" variable is a bad idea and
we should instead have distinct developer-oriented GUCs for each special
behavior we decide we need. I'm not particularly set on that, but
to me it seems like less of a mess to have just one.
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, robertmhaas@gmail.com, alvherre@2ndquadrant.com
Subject: Re: Regression tests vs existing users in an installation
In-Reply-To: <23690.1468854782@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox