On Wed, 2011-04-06 at 23:54 +0200, Jan Urbański wrote:
Ouch, just today I found a flaw in this, namely that it assumes the
lineno from the traceback always refers to the PL/Python function. If
you create a PL/Python function that imports some code, runs it, and
that code raises an
On mån, 2011-03-21 at 00:40 +0100, Jan Urbański wrote:
I finally got around to updating the PL/Python tracebacks patch. The
other day I was writing some very simple PL/Python code and the lack of
tracebacks is extremely annoying.
I tweaked this a bit to make the patch less invasive, and then
On 06/04/11 21:38, Peter Eisentraut wrote:
On mån, 2011-03-21 at 00:40 +0100, Jan Urbański wrote:
I finally got around to updating the PL/Python tracebacks patch. The
other day I was writing some very simple PL/Python code and the lack of
tracebacks is extremely annoying.
I tweaked this a
On 06/04/11 22:16, Jan Urbański wrote:
On 06/04/11 21:38, Peter Eisentraut wrote:
On mån, 2011-03-21 at 00:40 +0100, Jan Urbański wrote:
I finally got around to updating the PL/Python tracebacks patch. The
other day I was writing some very simple PL/Python code and the lack of
tracebacks is
On 20 March 2011 23:40, Jan Urbański wulc...@wulczer.org wrote:
I'll update the commitfest app for the 2011-Next commitfest, but if
someone would like to pick this up and include it in the 9.1 PL/Python
revamp pack, I'd be thrilled.
I would also be thrilled. I definitely share your sense of
On 07/03/11 22:55, Peter Eisentraut wrote:
On mån, 2011-03-07 at 14:19 +0100, Jan Urbański wrote:
On 07/03/11 14:01, Jan Urbański wrote:
On 07/03/11 13:53, Peter Eisentraut wrote:
On sön, 2011-03-06 at 13:14 +0100, Jan Urbański wrote:
But fixing raise plpy.Fatal()
to actually cause a FATAL
On ons, 2011-03-02 at 22:28 +0100, Jan Urbański wrote:
I did some tests with the attached test script, calling various of the
functions defined there and the error messages more or less made sense
(or at least were not worse than before).
Is that script part of the regression tests you added?
On sön, 2011-03-06 at 13:14 +0100, Jan Urbański wrote:
But fixing raise plpy.Fatal()
to actually cause a FATAL is something that should be extracted from
this patch and committed, even if the full patch does not make it.
Um, what? I didn't find any details about this in this thread, nor a
On 07/03/11 13:53, Peter Eisentraut wrote:
On ons, 2011-03-02 at 22:28 +0100, Jan Urbański wrote:
I did some tests with the attached test script, calling various of the
functions defined there and the error messages more or less made sense
(or at least were not worse than before).
Is that
On 07/03/11 13:53, Peter Eisentraut wrote:
On sön, 2011-03-06 at 13:14 +0100, Jan Urbański wrote:
But fixing raise plpy.Fatal()
to actually cause a FATAL is something that should be extracted from
this patch and committed, even if the full patch does not make it.
Um, what? I didn't find
On 07/03/11 14:01, Jan Urbański wrote:
On 07/03/11 13:53, Peter Eisentraut wrote:
On sön, 2011-03-06 at 13:14 +0100, Jan Urbański wrote:
But fixing raise plpy.Fatal()
to actually cause a FATAL is something that should be extracted from
this patch and committed, even if the full patch does not
On mån, 2011-03-07 at 14:19 +0100, Jan Urbański wrote:
On 07/03/11 14:01, Jan Urbański wrote:
On 07/03/11 13:53, Peter Eisentraut wrote:
On sön, 2011-03-06 at 13:14 +0100, Jan Urbański wrote:
But fixing raise plpy.Fatal()
to actually cause a FATAL is something that should be extracted
On 02/03/11 22:28, Jan Urbański wrote:
On 01/03/11 22:12, Peter Eisentraut wrote:
On tis, 2011-03-01 at 21:10 +0100, Jan Urbański wrote:
So you end up with a context message saying PL/Python function %s
and a detail message with the saved detail (if it's present) *and* the
traceback. The
On 26/02/11 16:10, Peter Eisentraut wrote:
On lör, 2011-02-26 at 09:34 +0100, Jan Urbański wrote:
- Original message -
On Thu, Feb 24, 2011 at 9:03 AM, Jan Urbański wulc...@wulczer.org
wrote:
On 24/02/11 14:10, Peter Eisentraut wrote:
Hm, perhaps, I put it in the details, because it
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= wulc...@wulczer.org writes:
I looked into putting the tracebacks in the context field, but IMHO it
doesn't really play out nice. PL/Python uses a errcontext callback to
populate the context field, so the reduntant information (the name of
the function) is
On 01/03/11 20:15, Tom Lane wrote:
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= wulc...@wulczer.org writes:
After thinking about it more I believe that the context field should
keep on being a one line indication of which function the message comes
from (and that's how it's done in PL/pgSQL for instance),
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= wulc...@wulczer.org writes:
Currently the traceback is added to the detail and the original
errdetail is preserved. So you'd get the detail line and the traceback
below it.
Hm? I'm talking about plpython_error_callback() and friends, which
AFAICS you haven't
On 01/03/11 20:35, Tom Lane wrote:
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= wulc...@wulczer.org writes:
Currently the traceback is added to the detail and the original
errdetail is preserved. So you'd get the detail line and the traceback
below it.
Hm? I'm talking about plpython_error_callback()
On Mar 1, 2011, at 12:10 PM, Jan Urbański wrote:
So you end up with a context message saying PL/Python function %s and
a detail message with the saved detail (if it's present) *and* the
traceback. The problem is that the name of the function is already in
the traceback, so there's no need for
On tis, 2011-03-01 at 21:10 +0100, Jan Urbański wrote:
So you end up with a context message saying PL/Python function %s
and a detail message with the saved detail (if it's present) *and* the
traceback. The problem is that the name of the function is already in
the traceback, so there's no
- Original message -
On Thu, Feb 24, 2011 at 9:03 AM, Jan Urbański wulc...@wulczer.org
wrote:
On 24/02/11 14:10, Peter Eisentraut wrote:
Hm, perhaps, I put it in the details, because it sounded like the place
to put information that is not that important, but still helpful. It's
On lör, 2011-02-26 at 09:34 +0100, Jan Urbański wrote:
- Original message -
On Thu, Feb 24, 2011 at 9:03 AM, Jan Urbański wulc...@wulczer.org
wrote:
On 24/02/11 14:10, Peter Eisentraut wrote:
Hm, perhaps, I put it in the details, because it sounded like the place
to put
On Thu, Feb 24, 2011 at 9:03 AM, Jan Urbański wulc...@wulczer.org wrote:
On 24/02/11 14:10, Peter Eisentraut wrote:
On tor, 2010-12-23 at 14:56 +0100, Jan Urbański wrote:
For errors originating from Python exceptions add the traceback as the
message detail. The patch tries to mimick Python's
On lör, 2011-02-12 at 02:00 -0700, Alex Hunsaker wrote:
PyString_AsString is used all over the place without any pfrees. But I
have no Idea how that pstrdup() is getting freed if at all.
pstrdup() like palloc() allocates memory from the current memory
context, which is freed automatically at
On lör, 2011-02-12 at 10:07 +0100, Jan Urbański wrote:
PLyUnicode_AsString(PyObject *unicode)
{
PyObject *o = PLyUnicode_Bytes(unicode);
char *rv = pstrdup(PyBytes_AsString(o));
Py_XDECREF(o);
return rv;
}
PyString_AsString is used all over the place
On tor, 2010-12-23 at 14:56 +0100, Jan Urbański wrote:
For errors originating from Python exceptions add the traceback as the
message detail. The patch tries to mimick Python's traceback.py module
behaviour as close as possible, icluding interleaving stack frames
with source code lines in the
On 24/02/11 14:10, Peter Eisentraut wrote:
On tor, 2010-12-23 at 14:56 +0100, Jan Urbański wrote:
For errors originating from Python exceptions add the traceback as the
message detail. The patch tries to mimick Python's traceback.py module
behaviour as close as possible, icluding interleaving
On 12/02/11 04:12, Alex Hunsaker wrote:
On Wed, Feb 9, 2011 at 02:10, Jan Urbański wulc...@wulczer.org wrote:
On 06/02/11 20:12, Jan Urbański wrote:
On 27/01/11 22:58, Jan Urbański wrote:
On 23/12/10 14:56, Jan Urbański wrote:
Here's a patch implementing traceback support for PL/Python
On Sat, Feb 12, 2011 at 01:50, Jan Urbański wulc...@wulczer.org wrote:
On 12/02/11 04:12, Alex Hunsaker wrote:
In PLy_traceback fname and prname look like they will leak (well as
much as a palloc() in an error path can leak I suppose).
But they're no palloc'd, no? fname is either a static
On 12/02/11 10:00, Alex Hunsaker wrote:
On Sat, Feb 12, 2011 at 01:50, Jan Urbański wulc...@wulczer.org wrote:
On 12/02/11 04:12, Alex Hunsaker wrote:
In PLy_traceback fname and prname look like they will leak (well as
much as a palloc() in an error path can leak I suppose).
But they're no
On Wed, Feb 9, 2011 at 4:10 AM, Jan Urbański wulc...@wulczer.org wrote:
On 06/02/11 20:12, Jan Urbański wrote:
On 27/01/11 22:58, Jan Urbański wrote:
On 23/12/10 14:56, Jan Urbański wrote:
Here's a patch implementing traceback support for PL/Python mentioned in
On Fri, Feb 11, 2011 at 08:45, Robert Haas robertmh...@gmail.com wrote:
On Wed, Feb 9, 2011 at 4:10 AM, Jan Urbański wulc...@wulczer.org wrote:
On 06/02/11 20:12, Jan Urbański wrote:
On 27/01/11 22:58, Jan Urbański wrote:
On 23/12/10 14:56, Jan Urbański wrote:
Here's a patch implementing
On Fri, Feb 11, 2011 at 11:22 AM, Alex Hunsaker bada...@gmail.com wrote:
On Fri, Feb 11, 2011 at 08:45, Robert Haas robertmh...@gmail.com wrote:
On Wed, Feb 9, 2011 at 4:10 AM, Jan Urbański wulc...@wulczer.org wrote:
On 06/02/11 20:12, Jan Urbański wrote:
On 27/01/11 22:58, Jan Urbański wrote:
Robert Haas robertmh...@gmail.com wrote:
Goodness... I picked up this patch the day before yesterday
because no-one was listed. That being said, if anyone else wants
to beat me to the punch of reviewing this, have at it! The more
eyes the merrier!
Sorry, I didn't see when you'd picked it
On Wed, Feb 9, 2011 at 02:10, Jan Urbański wulc...@wulczer.org wrote:
On 06/02/11 20:12, Jan Urbański wrote:
On 27/01/11 22:58, Jan Urbański wrote:
On 23/12/10 14:56, Jan Urbański wrote:
Here's a patch implementing traceback support for PL/Python mentioned in
On 06/02/11 20:12, Jan Urbański wrote:
On 27/01/11 22:58, Jan Urbański wrote:
On 23/12/10 14:56, Jan Urbański wrote:
Here's a patch implementing traceback support for PL/Python mentioned in
http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It's
an incremental patch on top of
On 27/01/11 22:58, Jan Urbański wrote:
On 23/12/10 14:56, Jan Urbański wrote:
Here's a patch implementing traceback support for PL/Python mentioned in
http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It's
an incremental patch on top of the plpython-refactor patch sent
On 23/12/10 14:56, Jan Urbański wrote:
Here's a patch implementing traceback support for PL/Python mentioned in
http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It's
an incremental patch on top of the plpython-refactor patch sent eariler.
Updated to master.
diff --git
Here's a patch implementing traceback support for PL/Python mentioned in
http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It's
an incremental patch on top of the plpython-refactor patch sent eariler.
Git branch for this patch:
https://github.com/wulczer/postgres/tree/tracebacks.
39 matches
Mail list logo
