On Wed, Aug 28, 2019 at 09:44:58PM -0400, Tom Lane wrote: > Well, it's useful if you just want the stdout back. But its name > is a bit misleading if the default behavior of psql is just as > safe. Not sure whether renaming it is worthwhile.
It is not that complicated enough to capture stdout with PostgresNode::psql either, so if we are making the default of one (PostgresNode::psql) look like the other (PostgresNode::safe_psql), then we lose no actual feature by dropping safe_psql. > Yeah, but only if the test cases are independent, which I think is > mostly not true in our TAP scripts. Otherwise you're just looking > at cascading errors. Yep. We have a couple of cases though where things are quite independent, like the 2PC suite divided into sequences of different transactions, but mostly there are dependencies between one step and the follow-up ones. > Yup, the tradeoff is people possibly having test scripts outside > our tree that would break, versus the possibility that we'll back-patch > test changes that don't behave as expected in back branches. I don't > know if the former is true, but I'm afraid the latter is a certainty > if we don't back-patch. Exactly, that's why I am wondering how wide breakages in those out-of-the-tree tests would go as we have PostgresNode since 9.6. Facing this choice makes me uneasy, which is why I would tend to only do incompatible things on HEAD. Another, safer, possibility would be to introduce in back-branches an extra psql-like routine enforcing errors which we use in our tests, to keep the former ones for compatibility, and to drop the old ones on HEAD. It is never fun to face sudden errors on a system when doing a minor upgrade. -- Michael
signature.asc
Description: PGP signature
