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 wi
Michael Paquier writes:
> On Wed, Aug 28, 2019 at 12:19:08PM -0400, Tom Lane wrote:
>> The attached patch just follows a mechanical rule of "set on_error_die
>> to 0 in exactly those calls where the surrounding code verifies the
>> exit code is what it expects".
> I am fine with that approach. T
On Wed, Aug 28, 2019 at 12:19:08PM -0400, Tom Lane wrote:
> The attached patch just follows a mechanical rule of "set on_error_die
> to 0 in exactly those calls where the surrounding code verifies the
> exit code is what it expects". That leads to a lot of code that
> looks like, say,
>
> # Inse
I wrote:
> After a brief review of node->psql calls in the TAP tests, I'm
> of the opinion that what we should do is revert fb57f40 and instead
> change PostgresNode::psql so that on_error_die defaults to 1, then
> fix the *very* small number of callers that need it to be zero.
> Otherwise we're ju
Michael Paquier writes:
> This is a follow-up of the discussion which happened here after Tom
> has committed fb57f40:
> https://www.postgresql.org/message-id/20190828012439.ga1...@paquier.xyz
> I have reviewed the TAP tests, and we have much more spots where it
> is better to use PostgresNode::sa
