Andres Freund <and...@anarazel.de> writes:
> On 2017-02-15 18:30:30 -0500, Tom Lane wrote:
>> If we tried to lock that down it'd be counterproductive for the reason
>> Andres mentions: sometimes you *want* to see what you get for other
>> settings.
> We could kinda address that by doing it in a separate file early in the
> schedule, which could just be commented out when doing something like
> this. But I'm still unconvinced it's worth caring.
Actually, that idea might be worth pursuing. Right now pg_regress.c has a
hard-wired notion that it should ALTER DATABASE SET certain parameters on
the regression database. The best you can say for that is it's ugly as
sin. It'd definitely be nicer if we could move that into someplace where
it's more readily adjustable. Having done that, locking down most stuff
by default might become more practical.
However, I'm not sure that just dumping the responsibility into an initial
test script is very workable. We'd need another copy for each contrib
and PL test suite, the isolation tests, yadda yadda. And maintaining
that many copies would be a nightmare. I think we'd need some way to have
pg_regress pick up the desired settings from a central place.
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
