Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iSMxw-0003hn-5j for pgsql-hackers@arkaria.postgresql.org; Wed, 06 Nov 2019 15:11:24 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1iSMxt-0003Cs-O2 for pgsql-hackers@arkaria.postgresql.org; Wed, 06 Nov 2019 15:11:21 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iSMxt-0003Cl-FB for pgsql-hackers@lists.postgresql.org; Wed, 06 Nov 2019 15:11:21 +0000 Received: from mail-qv1-xf43.google.com ([2607:f8b0:4864:20::f43]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iSMxq-0005mf-8f for pgsql-hackers@postgresql.org; Wed, 06 Nov 2019 15:11:21 +0000 Received: by mail-qv1-xf43.google.com with SMTP id s18so1429045qvr.4 for ; Wed, 06 Nov 2019 07:11:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=pRapoePWJ2tx7ZDEJmKR2cLm4EONGkWsrE5oPzs3uYA=; b=d3jLxSP2cgMdNwhqX/Co7SB7wuuEIQ37PUpDq+3Szf5V32z730IHeHKyDYKMpjV5Ng 7N+SslbSPp9//10zVt1XkTzlF+M6392IhQu8RZxmv5kB/gBuRM9yyMV5+ZBS6vOFD3sN BObLKbF6ObpCx1zSf7Tnxdwb7WaeL6/9Oayqnx7/AewFEaR1vtgAdKGBaq/DpjjnISOj 7s1fYdq7b7/Geq/56oZJ6bGDQISqc7svL0UBURoZBKYmI4YG/r91G2p9lmmiMzWa04W8 hoFQ/L8dcyG3nLya7qe11mnb6fPA1esaxU88aRr9oAB4RUBXH6roLexfV5rcB/BQLK+P 2mqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=pRapoePWJ2tx7ZDEJmKR2cLm4EONGkWsrE5oPzs3uYA=; b=QAt1fpjj3lMKUWHZYIF7GiPAu5/SF8VyG5yPWPVMFZxXcMFgs95mjLsMhWbHHNet30 /9CSNspmNPl2aOCt1gGUyWHJtPUXWLs5YFAimgiLSiy2UX1SbEI8AZOl59eD9hYa8ALX HHkFYHd50NiwtDjjArY9ZsSgsVxNxSEikej0Yxa0Stsh469V/MqMfGinK5RJbDaDj1xC feBOUPR7TW9Z2UpF71VnLokmMIMuoDUHdEMlZgYMFqFKMzCxMCyRuJpV9GRBkkuBQorp c2mZd3efdK/touT28eRNPwiqk1eRcNvbI2A3uiyy/y53acY+OD+rwu0ArUkhq6fIv+AS N6bg== X-Gm-Message-State: APjAAAUQDhDsFvL/LiJRzX/DgPzho0/JZzLXAK5fYlAyK0aLZvLS9PPZ ZBXP2M+7u/0IyOSXlFarG9WFow== X-Google-Smtp-Source: APXvYqwWY35s0OHOX54HLV8zQpUGK2CtNxhCYSU0MndgwPV1AJu+K9KfsOxCt1TIYY717uskwUGxlw== X-Received: by 2002:a05:6214:1427:: with SMTP id o7mr2700316qvx.83.1573053075519; Wed, 06 Nov 2019 07:11:15 -0800 (PST) Received: from nimloth.alvh.no-ip.org (ip-11-2-52-196.nyc.us.northamericancoax.com. [196.52.2.11]) by smtp.gmail.com with ESMTPSA id y186sm11433069qkd.71.2019.11.06.07.11.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Nov 2019 07:11:15 -0800 (PST) Received: by nimloth.alvh.no-ip.org (Postfix, from userid 1000) id 0D569300B5A; Wed, 6 Nov 2019 12:11:12 -0300 (-03) Date: Wed, 6 Nov 2019 12:11:12 -0300 From: Alvaro Herrera To: Pavel Stehule Cc: Michael Paquier , Mark Dilger , PostgreSQL-development Subject: Re: Checking return value of SPI_execute Message-ID: <20191106151112.GA12251@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2019-Nov-06, Pavel Stehule wrote: > My comment was about maybe obsolescence of this API. Probably it was > designed before exception introduction. > > For example - syntax error is ended by exception. Wrong numbers of argument > is signalized by error status. I didn't study this code, but maybe was much > more effective to raise exceptions inside SPI instead return status code. > These errors are finished by exceptions, but these exceptions coming from > different places. For me it looks strange, if some functions returns error > status, but can be ended by exception too. Yeah, I think I'd rather have more status codes and less exceptions, than the other way around. The problem with throwing exceptions for every kind of error is that we don't allow exceptions to be caught (per project policy) except to be rethrown. It seems like for errors where the SPI code can clean up its own resources (free memory, close portals etc), it should do such cleanup then return SPI_SYNTAX_ERROR or whatever and the caller can decide whether to turn this into an exception or handle in a different way; whereas for exceptions thrown by callees (say OOM) it would just propagate the exception. This mean callers are forced into adding code to check for return codes, but it allows more flexibility. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services