Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c1Nkx-0006qb-Ik for pgsql-sql@arkaria.postgresql.org; Tue, 01 Nov 2016 01:20:51 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1c1Nkw-0003Ph-TF for pgsql-sql@arkaria.postgresql.org; Tue, 01 Nov 2016 01:20:50 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1c1Nkw-0003PV-3U for pgsql-sql@postgresql.org; Tue, 01 Nov 2016 01:20:50 +0000 Received: from out2-smtp.messagingengine.com ([66.111.4.26]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1c1Nkt-0006O9-5c for pgsql-sql@postgresql.org; Tue, 01 Nov 2016 01:20:48 +0000 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 910E620A68; Mon, 31 Oct 2016 21:20:46 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Mon, 31 Oct 2016 21:20:46 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=aklaver.com; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=goIg5R5DfT9s3Z0 OL4OM+CcFUsI=; b=ZkUlBQdphRcCr7yTRhWIHgO9Y5Fy1BvSHr4MUxQQNBhAzEz BdBW//bvTiuaXImeH0kJAroohgOx/EwwUaCR+bf8YyZ39UQ5xDfWuRWvi4fMjJOB DaXnDXpBl9LN9ApRmWFj5VY/l3ZE2BDuiqheLRycHAtV2NZIhtHMWczT1fMs= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=goIg5R5DfT9s3Z0OL4OM+CcFUsI=; b=RApYa9sRzhjaKpX6VQZx 6p96syyKNpaZx+sq0ndSnKqap5EFwoIci9RjlcNTHNKVX069uw3v04RGus3/meiy 2gw/CqUL8MOAcUUoz2qL1WvZdFqmxHNv3U+v4iPs6pcsl8WibR5BY9lfQUOM0nN5 LTSiurNvNSq8sb6gs9ZVzXM= X-ME-Sender: X-Sasl-enc: iW9Cq+h165kWNYNwNfJZaqwRTcdg6LSY4WySjIii9FVr 1477963246 Received: from [192.168.1.2] (174-21-191-61.tukw.qwest.net [174.21.191.61]) by mail.messagingengine.com (Postfix) with ESMTPA id EA62EF29C9; Mon, 31 Oct 2016 21:20:45 -0400 (EDT) Subject: Re: Why does the PL/pgSQL compiler do this? To: Michael Moore References: <0520e6e1-8708-f58a-af0b-5624df7d01cf@aklaver.com> Cc: "David G. Johnston" , postgres list From: Adrian Klaver Message-ID: <98b610a2-6de4-443e-69cb-09edc8052e8f@aklaver.com> Date: Mon, 31 Oct 2016 18:20:45 -0700 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Pg-Spam-Score: -2.7 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-sql Precedence: bulk Sender: pgsql-sql-owner@postgresql.org On 10/31/2016 06:09 PM, Michael Moore wrote: > Thanks Adrian, but is ROLLBACK *_ever_* possible in PL/pgSQL? My > understanding is, "No". Well not directly. This is where the memory faded. As I understand it pl/pgsql uses savepoints under the hood for: https://www.postgresql.org/docs/9.5/static/plpgsql-control-structures.html#PLPGSQL-ERROR-TRAPPING When trying to figure this out in the past I found: RollbackAndReleaseCurrentSubTransaction(); in pl_exec.c So you are correct. > > On Mon, Oct 31, 2016 at 4:38 PM, Adrian Klaver > > wrote: > > On 10/31/2016 04:32 PM, Michael Moore wrote: > > I'm still a bit confused. If I replace the ROLLBACK; command with > ELEPHANT; the result is a syntax error. Why doesn't ROLLBACK; > produce > the same error since it is not valid in the LANGUAGE plpgsql. I > understand that "ROLLBACK TO SAVEPOINT" IS valid. But it's not > the same > thing. > > > I am guessing this: > > https://www.postgresql.org/docs/9.5/static/plpgsql-implementation.html > > " A disadvantage is that errors in a specific expression or command > cannot be detected until that part of the function is reached in > execution. (Trivial syntax errors will be detected during the > initial parsing pass, but anything deeper will not be detected until > execution.)" > > ROLLBACK might actually be valid at some point, ELEPHANT will not so > it caught in the trivial error stage. > > > On Mon, Oct 31, 2016 at 3:55 PM, Michael Moore > > >> wrote: > > Cool, thanks David, I'll give it a read. > > > On Mon, Oct 31, 2016 at 3:24 PM, David G. Johnston > > >> wrote: > > On Mon, Oct 31, 2016 at 3:13 PM, Michael Moore > >>wrote: > > Here is the complete function, but all you need to > look at > is the exception block. (I didn't write this code) > :-) I > will ask the question after the code. > ​[...]​ > > RETURN TRUE; > > EXCEPTION WHEN OTHERS THEN > > RAISE EXCEPTION '% %', SQLERRM, SQLSTATE; > > ROLLBACK; > > RETURN FALSE; > > END; > > $BODY$ > > LANGUAGE plpgsql VOLATILE > > COST 100; > > > So, here is the question. Why does the compiler not > catch: > > 1) ROLLBACK; is not a valid PL/pgSQL command > > > R > ​eading section ​41.10.2 at the linked page should > answer this part. > > > https://www.postgresql.org/docs/current/static/plpgsql-implementation.html > > > > > > > 2) ROLLBACK; and RETURN FALSE; can never be reached > > > > Similar to the above - though "static analysis" is yet a > step > beyond even what the syntax checking skipping covered above > would reveal. > > ​David J.​ > > > > > > -- > Adrian Klaver > adrian.klaver@aklaver.com > > -- Adrian Klaver adrian.klaver@aklaver.com -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql