Re: pl/python refactoring - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: pl/python refactoring
Date
Msg-id 1295389370.25598.4.camel@vanquo.pezone.net
Whole thread Raw
In response to Re: pl/python refactoring  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: pl/python refactoring  (Hitoshi Harada <umi.tanuki@gmail.com>)
Re: pl/python refactoring  (Alvaro Herrera <alvherre@commandprompt.com>)
Re: pl/python refactoring  (Jan Urbański <wulczer@wulczer.org>)
List pgsql-hackers
On mån, 2011-01-17 at 21:49 +0200, Peter Eisentraut wrote:
> On sön, 2011-01-02 at 12:41 +0100, Jan Urbański wrote:
> > Here they are. There are 16 patches in total. They amount to what's
> > currently in my refactor branch (and almost to what I've sent as the
> > complete refactor patch, while doing the splitting I discovered a few
> > useless hunks that I've discarded).
> 
> Committed 0001, rest later.

Today committed: 3, 5, 10, 11, 12, 13

Discussion:

#2: It looks like this loses some information/formatting in the error
message.  Should we keep the pointing arrow there?

--- a/src/pl/plpython/expected/plpython_error.out
+++ b/src/pl/plpython/expected/plpython_error.out
@@ -10,10 +10,7 @@ CREATE FUNCTION sql_syntax_error() RETURNS textSELECT sql_syntax_error();WARNING:  PL/Python:
plpy.SPIError:unrecognized error in PLy_spi_execute_queryCONTEXT:  PL/Python function "sql_syntax_error"
 
-ERROR:  syntax error at or near "syntax"
-LINE 1: syntax error
-        ^
-QUERY:  syntax error
+ERROR:  PL/Python: plpy.SPIError: syntax error at or near "syntax"CONTEXT:  PL/Python function "sql_syntax_error"/*
checkthe handling of uncaught python exceptions */
 

#7: This is unnecessary because the remaining fields are automatically
initialized with NULL.  The Python documentation uses initializations
like that.  The way I understand it, newer Python versions might add
more fields at the end, and they will rely on the fact that they get
automatically initialized even if the source code was for an older
version.  So I would rather not touch this, as it doesn't buy anything.

#16: This is probably pointless because pgindent will reformat this.




pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: test_fsync label adjustments
Next
From: Pavel Stehule
Date:
Subject: Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql