Robert Haas <robertmh...@gmail.com> writes: > On Sat, Jul 16, 2016 at 11:38 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> I'm coming to the conclusion that the only thing that will make this >> materially better in the long run is automatic enforcement of a convention >> about what role names may be created in the regression tests. See my >> response to Stephen just now for a concrete proposal.
> We could also do this by loading a C module during the regression > tests, which seems maybe less ugly than adding a GUC. Meh, I'm not convinced. As Michael points out, arranging for such a module to get loaded in an installcheck context would be difficult --- maybe not impossible, but complicated. Also, we'd have to add hook function calls in all the places it would need to get control; most of those places would probably be one-off hooks with no other conceivable use. And we'd still need to have a GUC, because I think it's inevitable that we'd need to be able to turn off the restrictions for specific tests. So that seems like a lot of work and complication just to make a GUC be custom to some undocumented extension rather than built-in. If we had no other debugging GUCs then there might be some point in rejecting this one, but we have a bunch: https://www.postgresql.org/docs/devel/static/runtime-config-developer.html > I don't particularly like your suggestion of spooky action at a > distance between force_parallel_mode and regression_test_mode. That > just seems kooky. It's certainly a judgment call as to which way is cleaner, but I don't understand your objection. There are plenty of ways in which multiple GUCs determine a given behavior already. Also, breaking this behavior into two variables would let us document the user-useful behavior (do this to test parallel safety of functions) in a different place from the developer-useful behavior (do this to make EXPLAIN lie to you, which surely has no possible use except for regression testing). Possibly a single "regression_test_mode" variable is a bad idea and we should instead have distinct developer-oriented GUCs for each special behavior we decide we need. I'm not particularly set on that, but to me it seems like less of a mess to have just one. 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
