Re: Regression tests vs existing users in an installation

From: Greg Stark <stark(at)mit(dot)edu>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Regression tests vs existing users in an installation
Date: 2016-07-16 12:19:58
Message-ID: CAM-w4HOOJxjGPwanV7hu_Yo71a+gx7XQx5_8uqefc=UaDk2vkg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 16 Jul 2016 12:59 pm, "Michael Paquier" <michael(dot)paquier(at)gmail(dot)com>
wrote:
>

> Thanks for doing this.

+1

Though I might highlight this as the kind of issue that a bug tracker would
help avoid falling through the cracks and make visible to newcomers.

> I am -1 for dropping the tests. We could just have a CFLAGS that adds
> an elog(ERROR) in CreateRole and checks that the created role has a
> wanted prefix, or have a plugin that uses the utility hook to do this
> filtering.

If we make a hidden regression_test_safety GUC then we could have
pg_regress enable it and have these specific tests disable it explicitly
with comments on why it's safe.

It might even be handy for other people writing application regression
tests depending on what other things it blocked.

A hook might even be possible to use the same way. pg_regress would have to
build and install a .so which might be tricky.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2016-07-16 12:20:58 Re: [BUG] pg_basebackup from disconnected standby fails
Previous Message Michael Paquier 2016-07-16 11:59:30 Re: Regression tests vs existing users in an installation