On 24.11.2011 23:56, Jan Urbański wrote:
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:
[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.
(Forgot to mention earlier: I committed the patch to master and
REL9_1_STABLE)
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.
Ok.
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.
Hmm, can the user also change the fields in the exception within python
code, or are they read-only? Is the spidata attribute in the exception
object visible to user code?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
