Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229]) by mail.postgresql.org (Postfix) with ESMTP id AD0D42EBA7C for ; Thu, 24 Nov 2011 17:57:10 -0400 (AST) Received: from wulczer.org ([109.74.195.157]) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1RThI5-0007Hc-0N for pgsql-hackers@postgresql.org; Thu, 24 Nov 2011 21:57:10 +0000 Received: from [85.59.228.11] (helo=[10.0.0.101]) by wulczer.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1RThHq-0005OQ-Gu; Thu, 24 Nov 2011 21:56:54 +0000 Message-ID: <4ECEBDA5.4000600@wulczer.org> Date: Thu, 24 Nov 2011 22:56:53 +0100 From: =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Heikki Linnakangas CC: Mika Eloranta , pgsql-hackers@postgresql.org Subject: Re: PL/Python SQL error code pass-through References: <0174B71F-7940-4819-BDC8-95EC8C9BA833@ohmu.fi> <4ECDFB26.1090203@wulczer.org> <4ECE5FA5.6060506@enterprisedb.com> In-Reply-To: <4ECE5FA5.6060506@enterprisedb.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Archive-Number: 201111/1450 X-Sequence-Number: 198935 On 24/11/11 16:15, Heikki Linnakangas wrote: > On 24.11.2011 10:07, Jan Urbański wrote: >> On 23/11/11 17:24, Mika Eloranta wrote: >>> Hi all, >>> >>> [PL/Python in 9.1 does not preserve SQLSTATE of errors] >> >> Oops, you're right, it's a regression from 9.0 behaviour. >> >> The fix looks good to me, I changed one place to indent with tabs >> instead of spaces and added a regression test. > > Thank you, both. Is there some other fields that we should propagate > from the original error message that we're missing? Like, context and > file/line information? Or are those left out on purpose? I wonder if we > should have a more wholesale approach, and store the whole ErrorData > struct somewhere, and only add some extra context information with > errcontext(). In case of SPI errors we're preserving the following from the original ErrorData: * sqlerrcode (as of Mika's patch) * detail * hint * query * internalpos that leaves us with the following which are not preserved: * message * context * detail_log The message is being constructed from the Python exception name and I think that's useful. The context is being taken by the traceback string. I'm not sure if detail_log is ever set in these types of errors, probably not? So I guess we're safe. The problem with storing the entire ErrorData struct is that this information has to be transformed to Python objects, because we attach it to the Python exception that gets raised and in case it bubbles all the way up to the topmost PL/Python function, we recover these Python objects and use them to construct the ereport call. While the exception is inside Python, user code can interact with it, so it'd be hard to have C pointers to non-Python stuff there. Cheers, Jan