Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1YDF0w-0003rR-5O for pgsql-docs@arkaria.postgresql.org; Mon, 19 Jan 2015 16:17:18 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1YDF0v-0002i9-Kf for pgsql-docs@arkaria.postgresql.org; Mon, 19 Jan 2015 16:17:17 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1YDF0u-0002gn-TD for pgsql-docs@postgresql.org; Mon, 19 Jan 2015 16:17:16 +0000 Received: from mail-we0-f178.google.com ([74.125.82.178]) by magus.postgresql.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1YDF0r-000341-Fk for pgsql-docs@postgresql.org; Mon, 19 Jan 2015 16:17:15 +0000 Received: by mail-we0-f178.google.com with SMTP id p10so32279287wes.9 for ; Mon, 19 Jan 2015 08:17:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=4lgRIpVIthXYN4ig4kxAx686Sn7F88obwgZy7lBFl14=; b=Ifn/II9wmzBeJXVVUqAxtifqR0tzkvyzPFUQDbnRfRUmGsG9tYl/BJx1ry84a3yD5Z /xyp/qstgGtp6IwLqi31h3Gqf0/TlDzZgzFKXPU1ttWxmOrgs9AGjhEt+6c9+6xyrwZJ YV641F5hD/HAD8L+c52kqkqXg53YSAEe0gCMXlhb9LN+ghHyy7Ekfar0bIrsoLCbEUjx 0kkrgm2LjJIf1+wqoMu+mNxqey9nccSoOp2037AXPg0Ur9OJMwWrdrPBMuik/emtrt3C TPadsXNf0q1TaZfigjEIcs3o6UhwfcJzmJXkN2bQkVXSOfHGKDunu3j/b74QxHuMNfZe MvLg== X-Gm-Message-State: ALoCoQkasRfBeqX+DjeZCRPVF/HcXYUftVSLxjt5bUFv4Egb54MDSTZeiASmpQVdojK5CxJEoldA X-Received: by 10.194.143.12 with SMTP id sa12mr3478681wjb.101.1421684231451; Mon, 19 Jan 2015 08:17:11 -0800 (PST) Received: from Markos-MacBook-Pro.local ([46.246.117.202]) by mx.google.com with ESMTPSA id ej10sm14787294wib.2.2015.01.19.08.17.10 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Jan 2015 08:17:10 -0800 (PST) Message-ID: <54BD2E05.2090004@joh.to> Date: Mon, 19 Jan 2015 17:17:09 +0100 From: Marko Tiikkaja User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Tom Lane CC: PG Docs Subject: Re: PL/PgSQL: stmt_fors and variable value after loop References: <54BD24C1.4060601@joh.to> <26441.1421682246@sss.pgh.pa.us> In-Reply-To: <26441.1421682246@sss.pgh.pa.us> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-docs Precedence: bulk Sender: pgsql-docs-owner@postgresql.org On 1/19/15 4:44 PM, Tom Lane wrote: > Marko Tiikkaja writes: >> But at least based on my understanding of exec_for_query() in pl_exec.c, >> a FOR loop over query results will always terminate with the values from >> the last row if at least one was found, regardless of whether EXIT was >> used or not. Is there a reason this detail has been left undefined in >> the documentation? If not, can we change the documentation? > > It seems to me that to do so would mostly be to encourage sloppy > programming practices, at the price of constraining future implementation > changes. Can you give a compelling example of a non-kluge usage for > such an assumption? What I'm doing would look something like this: CREATE FUNCTION parse_response(_response json) RETURNS void AS $$ DECLARE _AvailableAccounts json; _Currency text; _Balance text; BEGIN FOR _Currency, _Balance IN LOOP _AvailableAccounts := json_push(_AvailableAccounts, ); END LOOP; IF json_array_length(_AvailableAccounts) > 1 THEN -- use _AvailableAccounts ELSIF json_array_length(_AvailableAccounts) = 1 THEN -- use _Balance and _Currency ELSE RAISE EXCEPTION 'oops'; END IF; END $$ LANGUAGE plpgsql; Available workarounds right now would be, as far as I can tell: 1) Have separate variables which I assign to inside the loop, and use those in case the loop found exactly one row 2) Aggregate the (currency, balance) pairs into an array first, and decide based on the array's cardinality what to do 3) Use a count(*) OVER () inside the query and EXIT if that count is 1 4) Extract the values back from the sole element in the _AvailableAccounts array I don't particularly like any of those. .marko -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs