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 (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers