On 20.03.23 19:31, Greg Stark wrote: > So I took a look at this patch. The conflict is with 2fe3bdbd691 > committed by Peter Eisentraut which added error checks for pipes. > Afaics the behaviour is now for pipe commands returning non-zero to > cause an error*always* regardless of the setting of ON_ERROR_STOP.
Commit b0d8f2d983cb25d1035fae1cd7de214dd67809b4 adds SHELL_ERROR as a set to 'true' whenever a \! or backtick command has a nonzero exit code. So it'll need some rebasing to remove the duplicated work.
So it's now possible to do this:
\set result = `some command` \if :SHELL_ERROR -- maybe test SHELL_EXIT_CODE to see what kind of error \echo some command failed -- nah, just quit \q
\endif
> I'm not entirely sure that's sensible actually. If you write to a pipe > that ends in grep and it happens to produce no matching rows you may > actually be quite surprised when that causes your script to fail...
I agree that that would be quite surprising, and this feature would be a non-starter for them. But if we extended the SHELL_ERROR and SHELL_EXIT_CODE patch to handle output pipes (which maybe we should have done in the first place), the handling would look like this:
