Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oZ6kF-0001St-N7 for pgsql-hackers@arkaria.postgresql.org; Fri, 16 Sep 2022 08:30:43 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oZ6kE-00025X-2F for pgsql-hackers@arkaria.postgresql.org; Fri, 16 Sep 2022 08:30:42 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oZ6kD-00025O-NG for pgsql-hackers@lists.postgresql.org; Fri, 16 Sep 2022 08:30:41 +0000 Received: from mail-pg1-x52f.google.com ([2607:f8b0:4864:20::52f]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1oZ6kB-0002Hi-G1 for pgsql-hackers@lists.postgresql.org; Fri, 16 Sep 2022 08:30:40 +0000 Received: by mail-pg1-x52f.google.com with SMTP id q9so10584758pgq.8 for ; Fri, 16 Sep 2022 01:30:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:user-agent:references :in-reply-to:from:subject:cc:to:message-id:date:from:to:cc:subject :date; bh=fSmWGGuv9WJF5rxovze3eQ148zliIaSToKauZriHINo=; b=HbkgCnmTqK3u+hX5caRwjK8a5yeD4wi++oDT+kH/MS0tRadEzEyzMzixJUcO4sKPOS 5vQxGKnVafYmfMCA7Jc3Ic8WbFAzmGR3eoGFwccvSUI0x47paGP5Ei08CK9IX8QpfSK2 eRS+5WbiE/jch8I6n2q3/DxFzvNmUZ5QgnTHxS8s9J0cQb8mLQ1CYbsD5eCZyYvsKYYA UJ8LEt8Ab0h5vgQbPkBPcNZU7fqYUIBlOvsOhv9xtX3IZy5w+zktLz5PkfknAnX5obzo VVsHfm/l8nJ11mEvJARGTp4y5oFgRQcx1cgXYKgZU4W2g3MPSH1RrpWBdikc9P7F/XRu JeMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:user-agent:references :in-reply-to:from:subject:cc:to:message-id:date:x-gm-message-state :from:to:cc:subject:date; bh=fSmWGGuv9WJF5rxovze3eQ148zliIaSToKauZriHINo=; b=nkDKUhaMigTi0ZMrrCbjPIa5QuWXTP/J/mp1EIyyTWKY2yhJZlZeHzM8VBuVH4M2bk TwlzyLyuGPWak1WMVhyddoQpCZ/HnexSbT0TxXS75HjRR/GZm5HbqySA1aRbMG2GzzNj qD1rBIkY3hUMTyKEdxNj3td3k5TOzTAluWaWZId5lJntRW/DThb8ghfuX+TfFzd7bGjo 7FuSD668/2lsEKY8Xz2ywGwpVlkkQx2Q6hQkXFLUo4jWMA3/7w99eijchdvScHUv0oyh hEFoi+iRrfhFTSechs9qlcNmhq10nbOXSGoVJz60npzDTyvvR5fxekEo3ow9eYfUnLe4 vu8g== X-Gm-Message-State: ACrzQf36YQ2XuMudClqhZPjPW4LEvmPgLmf5hleJB4WPiXtVlW9vif5H ghqbnQdFZt5AcYTA8oMfBUc= X-Google-Smtp-Source: AMsMyM4iOoAei+qvhrGyLGyJWuWJyVSZrFcaeiILzv7UxYuhBA5+nDCZp3VSF3yeUBqqrQq6YspMBA== X-Received: by 2002:a63:69ca:0:b0:435:1347:b43b with SMTP id e193-20020a6369ca000000b004351347b43bmr3656844pgc.258.1663317038306; Fri, 16 Sep 2022 01:30:38 -0700 (PDT) Received: from localhost (KD036014041111.ppp-bb.dion.ne.jp. [36.14.41.111]) by smtp.gmail.com with ESMTPSA id oj6-20020a17090b4d8600b001fe39bda429sm955637pjb.38.2022.09.16.01.30.36 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Fri, 16 Sep 2022 01:30:37 -0700 (PDT) Date: Fri, 16 Sep 2022 17:30:35 +0900 (JST) Message-Id: <20220916.173035.322733707258561235.horikyota.ntt@gmail.com> To: bt22nakamorit@oss.nttdata.com Cc: pgsql-hackers@lists.postgresql.org Subject: Re: Make ON_ERROR_STOP stop on shell script failure From: Kyotaro Horiguchi In-Reply-To: References: User-Agent: Mew version 6.8 on Emacs 26.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk At Fri, 16 Sep 2022 15:55:33 +0900, bt22nakamorit wrote in > Hi, > > """\set ON_ERROR_STOP on""" stops any subsequent incoming query that > comes after an error of an SQL, but does not stop after a shell script > ran by """\! """ returning values other than 0, -1, or > 127, which suggests a failure in the result of the shell script. > > For example, suppose that below is an SQL file. > \set ON_ERROR_STOP on > SELECT 1; > \! false > SELECT 2; > > The current design allows SELECT 2 even though the shell script > returns a value indicating a failure. Since the "false" command did not "error out"? > I thought that this action is rather unexpected since, based on the > word """ON_ERROR_STOP""", ones may expect that failures of shell > scripts should halt the incoming instructions as well. > One clear solution is to let failures of shell script stop incoming > queries just like how errors of SQLs do currently. Thoughts? I'm not sure we want to regard any exit status from a succssful run as a failure. On the other hand, the proposed behavior seems useful to me. So +1 from me to the proposal, assuming the corresponding edit of the documentation happens. regards. -- Kyotaro Horiguchi NTT Open Source Software Center