Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1YDEOh-0002I9-27 for pgsql-docs@arkaria.postgresql.org; Mon, 19 Jan 2015 15:37:47 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1YDEOg-0005Y5-JJ for pgsql-docs@arkaria.postgresql.org; Mon, 19 Jan 2015 15:37:46 +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 1YDEOg-0005Xz-2p for pgsql-docs@postgresql.org; Mon, 19 Jan 2015 15:37:46 +0000 Received: from mail-la0-f54.google.com ([209.85.215.54]) by magus.postgresql.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1YDEOc-0002HH-I6 for pgsql-docs@postgresql.org; Mon, 19 Jan 2015 15:37:45 +0000 Received: by mail-la0-f54.google.com with SMTP id pv20so29484139lab.13 for ; Mon, 19 Jan 2015 07:37:39 -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 :subject:content-type:content-transfer-encoding; bh=vjCR1h5oFOavXSiT3CPUp+0V5gxt8hHJf7KjjUpXW7A=; b=bpOcj5IHX+lk9TmSKLaRr3gxLs8MX2mlue8qpXpYLiWLN4jmoAhLe/C4VGvTVw80cP mQsqMv1CGwKYNZoQ8LOQx8fn47vkRPEksaKutwtGU6UFXVXlbVIW4klW4IF57EcRl/m0 WC3Bwmwkl+CY3xzz+IlkWs1QX5bIFHaCn1kp7ZOBP89c/VsEIyeCSIazTEhIVOEJKokj J6IUFvlGgRXxN1Xavwj56NTsBqQsaNJTe3GLIn4YHRfaWXSX2KtNV64patvHdYJWqSe4 ig04jOXqG/Wt9A7M+t22D9i4LNNNpKQ8HLQ9LLlqAwOWxKF/+nimVMNUGaeOwMjUbRG8 /alw== X-Gm-Message-State: ALoCoQlHTADmCLYxjFSvZ80D63R1xjsocNUI/3MlX7jtXgpzXnllaCsQ7JSYf/YNuOLh6Auulw8D X-Received: by 10.112.30.71 with SMTP id q7mr32187556lbh.41.1421681859012; Mon, 19 Jan 2015 07:37:39 -0800 (PST) Received: from Markos-MacBook-Pro.local ([46.246.117.202]) by mx.google.com with ESMTPSA id yf10sm3174546lbb.9.2015.01.19.07.37.38 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Jan 2015 07:37:38 -0800 (PST) Message-ID: <54BD24C1.4060601@joh.to> Date: Mon, 19 Jan 2015 16:37:37 +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: PG Docs Subject: PL/PgSQL: stmt_fors and variable value after loop Content-Type: text/plain; charset=utf-8; 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 Hi, As far as I can tell, according to the documentation[1] the return value of this PL/PgSQL function is undefined: CREATE OR REPLACE FUNCTION public.foof() RETURNS integer LANGUAGE plpgsql AS $function$ declare _f1 int; begin for _f1 in select 1 loop end loop; return _f1; end $function$ 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? .marko [1]: http://www.postgresql.org/docs/9.4/static/plpgsql-control-structures.html#PLPGSQL-RECORDS-ITERATING -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs