On Fri, Mar 24, 2023 at 2:16 PM Corey Huinker <corey.huin...@gmail.com> wrote:
> > > 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. > > Dangit. Replied to Peter's email thinking he had gone off Greg's culling of the recipients. Re-culled.
