Re: psql - add SHOW_ALL_RESULTS option

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Julien Rouhaud <rjuju123(at)gmail(dot)com>, "shiy(dot)fnst(at)fujitsu(dot)com" <shiy(dot)fnst(at)fujitsu(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: psql - add SHOW_ALL_RESULTS option
Date: 2021-04-09 18:04:11
Message-ID: alpine.DEB.2.22.394.2104091947240.3439700@pseudo
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

>> Yep, it looks much better. I found it strange that the later did a reset but
>> was not doing the set.
>> Attached v2 does as you suggest.
> Close enough. I was thinking about this position of the attached,
> which is more consistent with the rest.

Given the structural complexity of the function, the end of the file
seemed like a good place to have an all-path-guaranteed reset.

I find it a little bit strange to have the Set at the upper level and the
Reset in many… but not all branches, though.

For instance the on_error_rollback_savepoint/svptcmd branch includes a
reset long after many other conditional resets, I cannot guess whether the
initial set is still active or has been long wiped out and this query is
just not cancellable.

Also, ISTM that in the worst case a cancellation request is sent to a
server which is idle, in which case it will be ignored, so the code should
be in no hurry to clean it, at least not at the price of code clarity.

Anyway, the place you suggest seems ok.


In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Mark Dilger 2021-04-09 18:50:32 Re: pg_amcheck contrib application
Previous Message James Coleman 2021-04-09 17:52:06 Re: Nicer error when connecting to standby with hot_standby=off