pg.ddx.io pgsql-docs@postgresql.org mailing list archive
help / color / mirror / Atom feed[PATCH] Fix documentation about PL/Python exception handling
10+ messages / 6 participants
[nested] [flat]
* [PATCH] Fix documentation about PL/Python exception handling
@ 2010-11-09 16:40 Marti Raudsepp <marti@juffo.org>
2010-11-10 14:07 ` Re: [PATCH] Fix documentation about PL/Python exception handling Euler Taveira de Oliveira <euler@timbira.com>
2010-11-26 23:50 ` Re: [PATCH] Fix documentation about PL/Python exception handling Bruce Momjian <bruce@momjian.us>
2011-02-09 21:44 ` Re: [PATCH] Fix documentation about PL/Python exception handling Peter Eisentraut <peter_e@gmx.net>
0 siblings, 3 replies; 10+ messages in thread
From: Marti Raudsepp @ 2010-11-09 16:40 UTC (permalink / raw)
To: pgsql-docs
Hi lists,
It seems that PL/Python exception functions (plpy.error, plpy.fatal)
and exception types (plpy.Error, plpy.Fatal) have never worked as
documented, and the behavior is quite surprising.
This is an attempt at properly documenting the current semantics. I
tested these behaviors on PostgreSQL 8.1.22 as well as 9.1alpha2.
Patch 1 updates the documentation in doc/src/sgml/plpython.sgml
Patch 2 adds tests to src/pl/plpython/sql/plpython_error.sql
Should I submit separate documentation patches for older maintenance
releases? Versions 8.1 - 8.4 contain the same incorrect text, but in
the "Database Access" section.
Regards,
Marti
Attachments: download all (2 files, .tar.gz)
0001-Document-current-PL-Python-exception-raising-semanti.patch (text/x-patch, 2.7K) download
From a9a83614624760d5adc4d0d31f9daa245b88cd72 Mon Sep 17 00:00:00 2001
From: Marti Raudsepp <marti@juffo.org>
Date: Tue, 9 Nov 2010 18:19:50 +0200
Subject: [PATCH 1/2] Document current PL/Python exception raising semantics
---
doc/src/sgml/plpython.sgml | 30 ++++++++++++++++++++----------
1 files changed, 20 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/plpython.sgml b/doc/src/sgml/plpython.sgml
index 9fc8808..320faab 100644
--- a/doc/src/sgml/plpython.sgml
+++ b/doc/src/sgml/plpython.sgml
@@ -950,16 +950,7 @@ $$ LANGUAGE plpythonu;
<literal>plpy.warning(<replaceable>msg</>)</literal>,
<literal>plpy.error(<replaceable>msg</>)</literal>, and
<literal>plpy.fatal(<replaceable>msg</>)</literal>.<indexterm><primary>elog</><secondary>in PL/Python</></indexterm>
- <function>plpy.error</function> and
- <function>plpy.fatal</function> actually raise a Python exception
- which, if uncaught, propagates out to the calling query, causing
- the current transaction or subtransaction to be aborted.
- <literal>raise plpy.Error(<replaceable>msg</>)</literal> and
- <literal>raise plpy.Fatal(<replaceable>msg</>)</literal> are
- equivalent to calling
- <function>plpy.error</function> and
- <function>plpy.fatal</function>, respectively.
- The other functions only generate messages of different
+ These functions generate messages of different
priority levels.
Whether messages of a particular priority are reported to the client,
written to the server log, or both is controlled by the
@@ -967,6 +958,25 @@ $$ LANGUAGE plpythonu;
<xref linkend="guc-client-min-messages"> configuration
variables. See <xref linkend="runtime-config"> for more information.
</para>
+
+ <para>
+ The <function>plpy.error</function> function actually raises a Python
+ exception which propagates out to the calling query, causing the current
+ transaction or subtransaction to be aborted. If multiple calls are made,
+ only the last message is reported. The exception has caveats: these errors
+ cannot be silenced by an except block, and Python exceptions raised in
+ except blocks will not be reported. The <function>plpy.fatal</function>
+ function immediately aborts execution and terminates the client connection.
+ </para>
+
+ <para>
+ To raise catchable errors, use
+ <literal>raise plpy.Error(<replaceable>msg</>)</literal>,
+ <literal>raise plpy.Fatal(<replaceable>msg</>)</literal> or native Python
+ exceptions. These have Python exception semantics. However, an unhandled
+ <literal>plpy.Fatal</literal> will still cause a PostgreSQL ERROR message to
+ be emitted.
+ </para>
</sect1>
<sect1 id="plpython-envar">
--
1.7.3.2
0002-Add-tests-for-current-PL-Python-exception-behavior.patch (text/x-patch, 5.4K) download
From 7ef8ec6f13906d6305db5142ba2415911e81852f Mon Sep 17 00:00:00 2001
From: Marti Raudsepp <marti@juffo.org>
Date: Tue, 9 Nov 2010 18:32:22 +0200
Subject: [PATCH 2/2] Add tests for current PL/Python exception behavior
---
src/pl/plpython/expected/plpython_error.out | 100 +++++++++++++++++++++++++++
src/pl/plpython/sql/plpython_error.sql | 89 ++++++++++++++++++++++++
2 files changed, 189 insertions(+), 0 deletions(-)
diff --git a/src/pl/plpython/expected/plpython_error.out b/src/pl/plpython/expected/plpython_error.out
index 1f24c13..18b7b99 100644
--- a/src/pl/plpython/expected/plpython_error.out
+++ b/src/pl/plpython/expected/plpython_error.out
@@ -121,3 +121,103 @@ SELECT valid_type('rick');
(1 row)
+/* raise plpy.Error */
+CREATE FUNCTION raise_error() RETURNS void
+ AS
+'raise plpy.Error("Raising error")'
+ LANGUAGE plpythonu;
+SELECT raise_error();
+ERROR: PL/Python: plpy.Error: Raising error
+CONTEXT: PL/Python function "raise_error"
+/* Broken behavior: raise plpy.Fatal. This is still mapped to PostgreSQL ERROR
+ * log level.
+ */
+CREATE FUNCTION broken_raise_fatal() RETURNS void
+ AS
+'raise plpy.Fatal("Raising fatal")'
+ LANGUAGE plpythonu;
+SELECT broken_raise_fatal();
+ERROR: PL/Python: plpy.Fatal: Raising fatal
+CONTEXT: PL/Python function "broken_raise_fatal"
+/* raising plpy.Error can be caught and ignored
+ */
+CREATE FUNCTION catch_error() RETURNS text
+ AS
+'try:
+ raise plpy.Error("catch me if you can!")
+except:
+ plpy.notice("gotcha")
+ return "retval"
+'
+ LANGUAGE plpythonu;
+SELECT catch_error();
+NOTICE: gotcha
+CONTEXT: PL/Python function "catch_error"
+ catch_error
+-------------
+ retval
+(1 row)
+
+/* catch plpy.Fatal by name
+ */
+CREATE FUNCTION catch_fatal() RETURNS text
+ AS
+'try:
+ raise plpy.Fatal("catch me if you can!")
+except plpy.Fatal:
+ return "retval"
+'
+ LANGUAGE plpythonu;
+SELECT catch_fatal();
+ catch_fatal
+-------------
+ retval
+(1 row)
+
+/* Broken behavior: plpy.error can be caught and the exception handler is
+ * executed, but cannot be silenced
+ */
+CREATE FUNCTION broken_error_catch() RETURNS text
+ AS
+'try:
+ plpy.error("catch me if you can!")
+except:
+ plpy.notice("caught but cannot ignore")
+ return "retval"
+'
+ LANGUAGE plpythonu;
+SELECT broken_error_catch();
+NOTICE: caught but cannot ignore
+CONTEXT: PL/Python function "broken_error_catch"
+ERROR: catch me if you can!
+CONTEXT: PL/Python function "broken_error_catch"
+/* Broken behavior: plpy.error can be caught, but errors in the exception
+ * handler are ignored
+ */
+CREATE FUNCTION broken_catch_exceptions() RETURNS void
+ AS
+'try:
+ plpy.error("catch me if you can!")
+except:
+ plpy.notice("caught but cannot ignore")
+ this is totally, broken-code
+'
+ LANGUAGE plpythonu;
+SELECT broken_catch_exceptions();
+NOTICE: caught but cannot ignore
+CONTEXT: PL/Python function "broken_catch_exceptions"
+ERROR: catch me if you can!
+CONTEXT: PL/Python function "broken_catch_exceptions"
+/* plpy.error can be overridden with another message
+ */
+CREATE FUNCTION catch_error_override() RETURNS void
+ AS
+'try:
+ plpy.error("catch me if you can!")
+except:
+ plpy.error("replaced with a new error")
+'
+ LANGUAGE plpythonu;
+SELECT catch_error_override();
+ERROR: replaced with a new error
+CONTEXT: PL/Python function "catch_error_override"
diff --git a/src/pl/plpython/sql/plpython_error.sql b/src/pl/plpython/sql/plpython_error.sql
index 5ca6849..99891e3 100644
--- a/src/pl/plpython/sql/plpython_error.sql
+++ b/src/pl/plpython/sql/plpython_error.sql
@@ -107,3 +107,92 @@ return None
LANGUAGE plpythonu;
SELECT valid_type('rick');
+
+/* raise plpy.Error */
+CREATE FUNCTION raise_error() RETURNS void
+ AS
+'raise plpy.Error("Raising error")'
+ LANGUAGE plpythonu;
+
+SELECT raise_error();
+
+/* Broken behavior: raise plpy.Fatal. This is still mapped to PostgreSQL ERROR
+ * log level.
+ */
+CREATE FUNCTION broken_raise_fatal() RETURNS void
+ AS
+'raise plpy.Fatal("Raising fatal")'
+ LANGUAGE plpythonu;
+
+SELECT broken_raise_fatal();
+
+/* raising plpy.Error can be caught and ignored
+ */
+CREATE FUNCTION catch_error() RETURNS text
+ AS
+'try:
+ raise plpy.Error("catch me if you can!")
+except:
+ plpy.notice("gotcha")
+ return "retval"
+'
+ LANGUAGE plpythonu;
+
+SELECT catch_error();
+
+/* catch plpy.Fatal by name
+ */
+CREATE FUNCTION catch_fatal() RETURNS text
+ AS
+'try:
+ raise plpy.Fatal("catch me if you can!")
+except plpy.Fatal:
+ return "retval"
+'
+ LANGUAGE plpythonu;
+
+SELECT catch_fatal();
+
+/* Broken behavior: plpy.error can be caught and the exception handler is
+ * executed, but cannot be silenced
+ */
+CREATE FUNCTION broken_error_catch() RETURNS text
+ AS
+'try:
+ plpy.error("catch me if you can!")
+except:
+ plpy.notice("caught but cannot ignore")
+ return "retval"
+'
+ LANGUAGE plpythonu;
+
+SELECT broken_error_catch();
+
+/* Broken behavior: plpy.error can be caught, but errors in the exception
+ * handler are ignored
+ */
+CREATE FUNCTION broken_catch_exceptions() RETURNS void
+ AS
+'try:
+ plpy.error("catch me if you can!")
+except:
+ plpy.notice("caught but cannot ignore")
+ this is totally, broken-code
+'
+ LANGUAGE plpythonu;
+
+SELECT broken_catch_exceptions();
+
+/* plpy.error can be overridden with another message
+ */
+CREATE FUNCTION catch_error_override() RETURNS void
+ AS
+'try:
+ plpy.error("catch me if you can!")
+except:
+ plpy.error("replaced with a new error")
+'
+ LANGUAGE plpythonu;
+
+SELECT catch_error_override();
+
--
1.7.3.2
* Re: [PATCH] Fix documentation about PL/Python exception handling
2010-11-09 16:40 [PATCH] Fix documentation about PL/Python exception handling Marti Raudsepp <marti@juffo.org>
@ 2010-11-10 14:07 ` Euler Taveira de Oliveira <euler@timbira.com>
2010-11-14 10:23 ` Re: [PATCH] Fix documentation about PL/Python exception handling Marti Raudsepp <marti@juffo.org>
2 siblings, 1 reply; 10+ messages in thread
From: Euler Taveira de Oliveira @ 2010-11-10 14:07 UTC (permalink / raw)
To: Marti Raudsepp <marti@juffo.org>; +Cc: pgsql-docs
Marti Raudsepp escreveu:
> Should I submit separate documentation patches for older maintenance
> releases? Versions 8.1 - 8.4 contain the same incorrect text, but in
> the "Database Access" section.
>
Sure. But bear in mind that we don't usually backpatch documentation unless
there is incorrect information; improvement belongs to HEAD.
--
Euler Taveira de Oliveira
http://www.timbira.com/
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: [PATCH] Fix documentation about PL/Python exception handling
2010-11-09 16:40 [PATCH] Fix documentation about PL/Python exception handling Marti Raudsepp <marti@juffo.org>
2010-11-10 14:07 ` Re: [PATCH] Fix documentation about PL/Python exception handling Euler Taveira de Oliveira <euler@timbira.com>
@ 2010-11-14 10:23 ` Marti Raudsepp <marti@juffo.org>
2010-11-15 20:25 ` Re: [PATCH] Fix documentation about PL/Python exception handling Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 10+ messages in thread
From: Marti Raudsepp @ 2010-11-14 10:23 UTC (permalink / raw)
To: Euler Taveira de Oliveira <euler@timbira.com>; +Cc: pgsql-docs
On Wed, Nov 10, 2010 at 16:07, Euler Taveira de Oliveira
<euler@timbira.com> wrote:
> Sure. But bear in mind that we don't usually backpatch documentation unless
> there is incorrect information; improvement belongs to HEAD.
Yeah, it is quite incorrect (as you can see by comparing test results
from 1st post with the documentation).
Attached is a documentation patch that will apply to PostgreSQL 8.1 - 8.4
Regards,
Marti
Attachments:
0001-pg84-Document-current-PL-Python-exception-raising-semanti.patch (text/x-patch, 2.6K) download
From 190d58287b750ad7492485faaf829f262b93e39e Mon Sep 17 00:00:00 2001
From: Marti Raudsepp <marti@juffo.org>
Date: Sun, 14 Nov 2010 11:24:43 +0200
Subject: [PATCH] Document current PL/Python exception raising semantics
---
doc/src/sgml/plpython.sgml | 30 ++++++++++++++++++++----------
1 files changed, 20 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/plpython.sgml b/doc/src/sgml/plpython.sgml
index 4944b8a..d567f10 100644
--- a/doc/src/sgml/plpython.sgml
+++ b/doc/src/sgml/plpython.sgml
@@ -428,16 +428,7 @@ $$ LANGUAGE plpythonu;
<literal>plpy.warning(<replaceable>msg</>)</literal>,
<literal>plpy.error(<replaceable>msg</>)</literal>, and
<literal>plpy.fatal(<replaceable>msg</>)</literal>.<indexterm><primary>elog</><secondary>in PL/Python</></indexterm>
- <function>plpy.error</function> and
- <function>plpy.fatal</function> actually raise a Python exception
- which, if uncaught, propagates out to the calling query, causing
- the current transaction or subtransaction to be aborted.
- <literal>raise plpy.ERROR(<replaceable>msg</>)</literal> and
- <literal>raise plpy.FATAL(<replaceable>msg</>)</literal> are
- equivalent to calling
- <function>plpy.error</function> and
- <function>plpy.fatal</function>, respectively.
- The other functions only generate messages of different
+ These functions generate messages of different
priority levels.
Whether messages of a particular priority are reported to the client,
written to the server log, or both is controlled by the
@@ -536,6 +527,25 @@ $$ LANGUAGE plpythonu;
<literal>struct</>, <literal>time</>, <literal>whrandom</>, and
<literal>zlib</>.
</para>
+
+ <para>
+ The <function>plpy.error</function> function actually raises a Python
+ exception which propagates out to the calling query, causing the current
+ transaction or subtransaction to be aborted. If multiple calls are made,
+ only the last message is reported. The exception has caveats: these errors
+ cannot be silenced by an except block, and Python exceptions raised in
+ except blocks will not be reported. The <function>plpy.fatal</function>
+ function immediately aborts execution and terminates the client connection.
+ </para>
+
+ <para>
+ To raise catchable errors, use
+ <literal>raise plpy.Error(<replaceable>msg</>)</literal>,
+ <literal>raise plpy.Fatal(<replaceable>msg</>)</literal> or native Python
+ exceptions. These have Python exception semantics. However, an unhandled
+ <literal>plpy.Fatal</literal> will still cause a PostgreSQL ERROR message to
+ be emitted.
+ </para>
</sect1>
]]>
--
1.7.3.2
* Re: [PATCH] Fix documentation about PL/Python exception handling
2010-11-09 16:40 [PATCH] Fix documentation about PL/Python exception handling Marti Raudsepp <marti@juffo.org>
2010-11-10 14:07 ` Re: [PATCH] Fix documentation about PL/Python exception handling Euler Taveira de Oliveira <euler@timbira.com>
2010-11-14 10:23 ` Re: [PATCH] Fix documentation about PL/Python exception handling Marti Raudsepp <marti@juffo.org>
@ 2010-11-15 20:25 ` Tom Lane <tgl@sss.pgh.pa.us>
2010-11-15 21:21 ` Re: [PATCH] Fix documentation about PL/Python exception handling Marti Raudsepp <marti@juffo.org>
2010-11-19 03:29 ` Re: [PATCH] Fix documentation about PL/Python exception handling Greg Smith <greg@2ndquadrant.com>
0 siblings, 2 replies; 10+ messages in thread
From: Tom Lane @ 2010-11-15 20:25 UTC (permalink / raw)
To: Marti Raudsepp <marti@juffo.org>; +Cc: Euler Taveira de Oliveira <euler@timbira.com>; pgsql-docs
Marti Raudsepp <marti@juffo.org> writes:
> On Wed, Nov 10, 2010 at 16:07, Euler Taveira de Oliveira
> <euler@timbira.com> wrote:
>> Sure. But bear in mind that we don't usually backpatch documentation unless
>> there is incorrect information; improvement belongs to HEAD.
> Yeah, it is quite incorrect (as you can see by comparing test results
> from 1st post with the documentation).
> Attached is a documentation patch that will apply to PostgreSQL 8.1 - 8.4
Hmmm ... I'm less than excited about documenting agreed-to-be-broken
behavior in exquisite detail. Doing so will just encourage people to
rely on it. It's particularly unfriendly to document it in detail
without pointing out that it's likely to change.
My inclination is to forget about these doc changes and spend our time
on fixing the behavior instead.
regards, tom lane
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: [PATCH] Fix documentation about PL/Python exception handling
2010-11-09 16:40 [PATCH] Fix documentation about PL/Python exception handling Marti Raudsepp <marti@juffo.org>
2010-11-10 14:07 ` Re: [PATCH] Fix documentation about PL/Python exception handling Euler Taveira de Oliveira <euler@timbira.com>
2010-11-14 10:23 ` Re: [PATCH] Fix documentation about PL/Python exception handling Marti Raudsepp <marti@juffo.org>
2010-11-15 20:25 ` Re: [PATCH] Fix documentation about PL/Python exception handling Tom Lane <tgl@sss.pgh.pa.us>
@ 2010-11-15 21:21 ` Marti Raudsepp <marti@juffo.org>
1 sibling, 0 replies; 10+ messages in thread
From: Marti Raudsepp @ 2010-11-15 21:21 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Euler Taveira de Oliveira <euler@timbira.com>; pgsql-docs
On Mon, Nov 15, 2010 at 22:25, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> My inclination is to forget about these doc changes and spend our time
> on fixing the behavior instead.
I thought the first step in fixing a problem is admitting the problem ;)
But you raise a fair point.
Regards,
Marti
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: [PATCH] Fix documentation about PL/Python exception handling
2010-11-09 16:40 [PATCH] Fix documentation about PL/Python exception handling Marti Raudsepp <marti@juffo.org>
2010-11-10 14:07 ` Re: [PATCH] Fix documentation about PL/Python exception handling Euler Taveira de Oliveira <euler@timbira.com>
2010-11-14 10:23 ` Re: [PATCH] Fix documentation about PL/Python exception handling Marti Raudsepp <marti@juffo.org>
2010-11-15 20:25 ` Re: [PATCH] Fix documentation about PL/Python exception handling Tom Lane <tgl@sss.pgh.pa.us>
@ 2010-11-19 03:29 ` Greg Smith <greg@2ndquadrant.com>
2010-11-19 08:35 ` Re: [PATCH] Fix documentation about PL/Python exception handling Marti Raudsepp <marti@juffo.org>
1 sibling, 1 reply; 10+ messages in thread
From: Greg Smith @ 2010-11-19 03:29 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Marti Raudsepp <marti@juffo.org>; Euler Taveira de Oliveira <euler@timbira.com>; pgsql-docs
Tom Lane wrote:
> Hmmm ... I'm less than excited about documenting agreed-to-be-broken
> behavior in exquisite detail. Doing so will just encourage people to
> rely on it. It's particularly unfriendly to document it in detail
> without pointing out that it's likely to change.
>
> My inclination is to forget about these doc changes and spend our time
> on fixing the behavior instead.
>
The open question for this one then is the right way for exceptions to
act. Marti, since you've looked at this a bit already, any thoughts on
what that should look like? You initially commented that what happens
was surprising, but I'm not clear on what you expected to happen instead.
--
Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD
PostgreSQL Training, Services and Support www.2ndQuadrant.us
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: [PATCH] Fix documentation about PL/Python exception handling
2010-11-09 16:40 [PATCH] Fix documentation about PL/Python exception handling Marti Raudsepp <marti@juffo.org>
2010-11-10 14:07 ` Re: [PATCH] Fix documentation about PL/Python exception handling Euler Taveira de Oliveira <euler@timbira.com>
2010-11-14 10:23 ` Re: [PATCH] Fix documentation about PL/Python exception handling Marti Raudsepp <marti@juffo.org>
2010-11-15 20:25 ` Re: [PATCH] Fix documentation about PL/Python exception handling Tom Lane <tgl@sss.pgh.pa.us>
2010-11-19 03:29 ` Re: [PATCH] Fix documentation about PL/Python exception handling Greg Smith <greg@2ndquadrant.com>
@ 2010-11-19 08:35 ` Marti Raudsepp <marti@juffo.org>
0 siblings, 0 replies; 10+ messages in thread
From: Marti Raudsepp @ 2010-11-19 08:35 UTC (permalink / raw)
To: Greg Smith <greg@2ndquadrant.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Euler Taveira de Oliveira <euler@timbira.com>; pgsql-docs
On Fri, Nov 19, 2010 at 05:29, Greg Smith <greg@2ndquadrant.com> wrote:
> The open question for this one then is the right way for exceptions to act.
> Marti, since you've looked at this a bit already, any thoughts on what that
> should look like? You initially commented that what happens was surprising,
> but I'm not clear on what you expected to happen instead.
The documented behavior would make a lot more sense.
For instance, currently, when you call plpy.error(), the exception
that's thrown can be caught, but even if you handle it, the function
still ends up failing. Similarly you CANNOT handle SQL errors -- at
all! All errors are fatal.
CREATE FUNCTION foo() RETURNS text
AS
'try:
plpy.execute("SELECT syntax error")
except:
plpy.notice("exception caught but cannot ignore")
return "retval"
'
LANGUAGE plpythonu;
WARNING: PL/Python: plpy.SPIError: unrecognized error in PLy_spi_execute_query
CONTEXT: PL/Python function "foo"
NOTICE: exception caught but cannot ignore
CONTEXT: PL/Python function "foo"
ERROR: column "syntax" does not exist
LINE 1: SELECT syntax error
^
QUERY: SELECT syntax error
CONTEXT: PL/Python function "foo"
Notice how the return value in the above is ignored, although the
NOTICE is still output. Any new exceptions raised in the exception
handler -- such as coding errors -- are also silently ignored.
Another surprise is that plpy.Error and plpy.Fatal are just empty
exception subclasses -- they behave nothing like
plpy.error()/plpy.fatal(). Since they're normal Python exceptions,
they can be caught and silenced. But an unhandled plpy.Fatal still
results in an ERROR level message, go figure.
I'm surprised that PL/Python got merged into Postgres at all without
proper error handling.
Regards,
Marti
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: [PATCH] Fix documentation about PL/Python exception handling
2010-11-09 16:40 [PATCH] Fix documentation about PL/Python exception handling Marti Raudsepp <marti@juffo.org>
@ 2010-11-26 23:50 ` Bruce Momjian <bruce@momjian.us>
2010-12-01 06:10 ` Re: [PATCH] Fix documentation about PL/Python exception handling Greg Smith <greg@2ndquadrant.com>
2 siblings, 1 reply; 10+ messages in thread
From: Bruce Momjian @ 2010-11-26 23:50 UTC (permalink / raw)
To: Marti Raudsepp <marti@juffo.org>; +Cc: pgsql-docs
Added to TODO:
/* PL/Python */ Add: |Improve behaviour of exception functions
and types
---------------------------------------------------------------------------
Marti Raudsepp wrote:
> Hi lists,
>
> It seems that PL/Python exception functions (plpy.error, plpy.fatal)
> and exception types (plpy.Error, plpy.Fatal) have never worked as
> documented, and the behavior is quite surprising.
>
> This is an attempt at properly documenting the current semantics. I
> tested these behaviors on PostgreSQL 8.1.22 as well as 9.1alpha2.
>
> Patch 1 updates the documentation in doc/src/sgml/plpython.sgml
> Patch 2 adds tests to src/pl/plpython/sql/plpython_error.sql
>
> Should I submit separate documentation patches for older maintenance
> releases? Versions 8.1 - 8.4 contain the same incorrect text, but in
> the "Database Access" section.
>
> Regards,
> Marti
[ Attachment, skipping... ]
[ Attachment, skipping... ]
>
> --
> Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-docs
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: [PATCH] Fix documentation about PL/Python exception handling
2010-11-09 16:40 [PATCH] Fix documentation about PL/Python exception handling Marti Raudsepp <marti@juffo.org>
2010-11-26 23:50 ` Re: [PATCH] Fix documentation about PL/Python exception handling Bruce Momjian <bruce@momjian.us>
@ 2010-12-01 06:10 ` Greg Smith <greg@2ndquadrant.com>
0 siblings, 0 replies; 10+ messages in thread
From: Greg Smith @ 2010-12-01 06:10 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: Marti Raudsepp <marti@juffo.org>; pgsql-docs
Bruce Momjian wrote:
> Added to TODO:
>
> /* PL/Python */ Add: |Improve behaviour of exception functions
> and types
>
I updated that to also link to Marti's message with more details about
the problem and potential solutions here, to speed up future archive
trawling. At this point I think the only sensible thing is to mark the
submitted documentation patch "Returned with feedback". Then we wait to
see if someone gets motivated to provide the more invasive behavior fix
that seems the preferred improvement here instead. Maybe there's an
advance slimmed down docs patch that makes sense too, for briefly
documenting the limitations without so much detail that the description
turns into a backward compatibility requirement.
--
Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: [PATCH] Fix documentation about PL/Python exception handling
2010-11-09 16:40 [PATCH] Fix documentation about PL/Python exception handling Marti Raudsepp <marti@juffo.org>
@ 2011-02-09 21:44 ` Peter Eisentraut <peter_e@gmx.net>
2 siblings, 0 replies; 10+ messages in thread
From: Peter Eisentraut @ 2011-02-09 21:44 UTC (permalink / raw)
To: Marti Raudsepp <marti@juffo.org>; +Cc: pgsql-docs
On tis, 2010-11-09 at 18:40 +0200, Marti Raudsepp wrote:
> It seems that PL/Python exception functions (plpy.error, plpy.fatal)
> and exception types (plpy.Error, plpy.Fatal) have never worked as
> documented, and the behavior is quite surprising.
This is now changed in 9.1devel, so I consider this matter closed.
^ permalink raw reply [nested|flat] 10+ messages in thread
end of thread, other threads:[~2011-02-09 21:44 UTC | newest]
Thread overview: 10+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2010-11-09 16:40 [PATCH] Fix documentation about PL/Python exception handling Marti Raudsepp <marti@juffo.org>
2010-11-10 14:07 ` Euler Taveira de Oliveira <euler@timbira.com>
2010-11-14 10:23 ` Marti Raudsepp <marti@juffo.org>
2010-11-15 20:25 ` Tom Lane <tgl@sss.pgh.pa.us>
2010-11-15 21:21 ` Marti Raudsepp <marti@juffo.org>
2010-11-19 03:29 ` Greg Smith <greg@2ndquadrant.com>
2010-11-19 08:35 ` Marti Raudsepp <marti@juffo.org>
2010-11-26 23:50 ` Bruce Momjian <bruce@momjian.us>
2010-12-01 06:10 ` Greg Smith <greg@2ndquadrant.com>
2011-02-09 21:44 ` Peter Eisentraut <peter_e@gmx.net>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox