Re: pl/python refactoring

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Jan Urbański <wulczer(at)wulczer(dot)org>
Cc: Postgres - Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pl/python refactoring
Date: 2011-01-18 22:22:50
Message-ID: 1295389370.25598.4.camel@vanquo.pezone.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 text
SELECT sql_syntax_error();
WARNING: PL/Python: plpy.SPIError: unrecognized error in PLy_spi_execute_query
CONTEXT: 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"
/* check the 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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2011-01-18 22:22:53 Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql
Previous Message Bruce Momjian 2011-01-18 22:21:00 Re: test_fsync label adjustments