On Fri, Mar 24, 2023 at 11:07 AM Peter Eisentraut < peter.eisentr...@enterprisedb.com> wrote:
> 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: SELECT ... \g grep Frobozz \if :SHELL_ERROR SELECT :SHELL_EXIT_CODE = 1 AS grep_found_nothing \gset \if :grep_found_nothing ...not-a-real-error handling... \else ...regular error handling... \endif \endif ...and that would be the solution for people who wanted to do something more nuanced than ON_ERROR_STOP.
