Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1brPdT-0006TL-EN for pgsql-sql@arkaria.postgresql.org; Tue, 04 Oct 2016 13:19:55 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1brPdT-0003Sj-10 for pgsql-sql@arkaria.postgresql.org; Tue, 04 Oct 2016 13:19:55 +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_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1brPdS-0003Sb-FW for pgsql-sql@postgresql.org; Tue, 04 Oct 2016 13:19:54 +0000 Received: from out4-smtp.messagingengine.com ([66.111.4.28]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1brPdN-00064M-GL for pgsql-sql@postgresql.org; Tue, 04 Oct 2016 13:19:53 +0000 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 5E30E20B75; Tue, 4 Oct 2016 09:19:46 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Tue, 04 Oct 2016 09:19:46 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=aklaver.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=okACY7XmbULraN29pAdCUKlx8Bs=; b=ihCutw X6dJ0Q03S34QxunRSpOVyPkWCGMR5IZsCktR4Ni3anQl0JNT/b2K97JuhdvpLtfe qxv2vUZwyAr4raGrIfuKvpHNG1o5kGO1+5lA+sJVkOjKoqoJOOWKrRwXRTKfqyqd 87zAffvMBr1tbi9cpEuTJJQY1hKVIoOb+UU/0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=okACY7XmbULraN2 9pAdCUKlx8Bs=; b=jX8u9ZEaY3u0s+cxyXxTcgLoGsVv3OzmSxYQmcOnDx8vTzo roP/NZ1s5ctDz9nzh1RdW30mZ8pvGau+dmozori81xP7leFLEGWxhl6zhoCdoi50 oVQi+QPzRYZNrOyoRMPgEYs5sZlnXm+fjPuGHadFh5XzlcY29FdrjW6qbdcc= X-Sasl-enc: 5SGLSpRQ71rKSP8qRh5tSx1CLVY03jf2K80LmYW3rUYs 1475587186 Received: from [192.168.1.2] (174-21-85-118.tukw.qwest.net [174.21.85.118]) by mail.messagingengine.com (Postfix) with ESMTPA id D4719CC07C; Tue, 4 Oct 2016 09:19:45 -0400 (EDT) Subject: Re: PLPython and named arguments To: Andrey Avakimov , Pgsql Sql References: <1475583602.246825.24420.25624@mail.rambler.ru> From: Adrian Klaver Message-ID: Date: Tue, 4 Oct 2016 06:19:45 -0700 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <1475583602.246825.24420.25624@mail.rambler.ru> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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/04/2016 05:20 AM, Andrey Avakimov wrote: > Hello > > My question is about plpython behavior. In some cases procedure ignores > named arguments and raises an error like: > > UnboundLocalError: local variable 'arg_from' referenced before assignment Because of this?: https://www.postgresql.org/docs/9.6/static/plpython-funcs.html " The arguments are set as global variables. Because of the scoping rules of Python, this has the subtle consequence that an argument variable cannot be reassigned inside the function to the value of an expression that involves the variable name itself, unless the variable is redeclared as global in the block. For example, the following won't work: CREATE FUNCTION pystrip(x text) RETURNS text AS $$ x = x.strip() # error return x $$ LANGUAGE plpythonu; because assigning to x makes x a local variable for the entire block, and so the x on the right-hand side of the assignment refers to a not-yet-assigned local variable x, not the PL/Python function parameter. Using the global statement, this can be made to work: CREATE FUNCTION pystrip(x text) RETURNS text AS $$ global x x = x.strip() # ok now return x $$ LANGUAGE plpythonu; But it is advisable not to rely on this implementation detail of PL/Python. It is better to treat the function parameters as read-only." So: test=# select * from pystrip('test '); ERROR: UnboundLocalError: local variable 'x' referenced before assignment CONTEXT: Traceback (most recent call last): PL/Python function "pystrip", line 2, in x = x.strip() # error PL/Python function "pystrip" > > This can be solved by using such code: > > arg_from, arg_to = args > > But the reasons of such behavior are still unclear. > > Does anyone faced this thing? > > I will gladly provide any further information if needed. > > Best Regards, > Andrew > -- 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