Re: Regression tests vs existing users in an installation

Greg Stark <stark@mit.edu>

From: Greg Stark <stark@mit.edu>
To: Michael Paquier <michael.paquier@gmail.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2016-07-16T12:19:58Z
Lists: pgsql-hackers
On 16 Jul 2016 12:59 pm, "Michael Paquier" <michael.paquier@gmail.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.

Commits

  1. Move rolenames test out of the core regression tests.

  2. Add an enforcement mechanism for global object names in regression tests.

  3. Fix regression tests to use only global names beginning with "regress_".

  4. Disallow user-created replication origins named "pg_xxx".