Re: pgsql: Adjust interaction of CREATEROLE with role properties.

On Fri, Jan 27, 2023 at 08:27:40AM -0500, Andrew Dunstan wrote:
> On 2023-01-26 Th 22:18, Tom Lane wrote:
> > Michael Paquier <michael(at)paquier(dot)xyz> writes:
> >> On Thu, Jan 26, 2023 at 09:08:23PM -0500, Tom Lane wrote:
> >>> Is it worth checking for leftover regress_xxx tablespaces as well as
> >>> roles?
> >> Guess so. If this is to be applied to everything that fails under the
> >> naming restrictions, there could be a point in doing the same for
> >> databases, subscriptions and replication origins. Now the argument
> >> has less weight for these object types, surely, compared to roles and
> >> tbspaces.
> > By the time we've spun up a new backend, we might as well do more
> > than one query, so it seems like we might as well check everything
> > that's globally visible.
> >
> > However ... this'd only cover mistakes of this kind in the core
> > regression tests. Is there a way to cover contrib's installcheck
> > (without adding an additional psql run to each module's tests)?
> >
> > Maybe we need to enforce this at some other level than the tests
> > themselves, perhaps in pg_regress?
>
> Yeah, that seems like a better way to go. Then it would even apply to
> external project tests.

Maybe this could be done by creating a pg_dump ?

The dump could be grepped (like pg_restore -l |perl -pe '/ROLE|.../')
for offending objects.

And the dump could be re-used for other things, like not re-running
regression tests in pg_upgrade and 027_stream_regress.

I don't know whether the pg_dump would be run directly by pg_regress or
something else.

--
Justin