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 e
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
>>> trac
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
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 20 March 2011 23:40, Jan Urbański 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 frustration
about t
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 act
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 b
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 p
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
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).
>
> I
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 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 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
>>> traceb
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 n
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
On 01/03/11 20:35, Tom Lane wrote:
> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= 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,
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= 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 changed the behavi
On 01/03/11 20:15, Tom Lane wrote:
> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= 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), and the deta
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= 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 always there. If that
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
>>> wrote:
On 24/02/11 14:10, Peter Eisentraut wrote:
Hm, perhaps, I put it in the details, because it sou
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
> > 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
- Original message -
> On Thu, Feb 24, 2011 at 9:03 AM, Jan Urbański
> 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
> > kind of na
On Thu, Feb 24, 2011 at 9:03 AM, Jan Urbański 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 traceback.py
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 interle
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 t
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 a
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 s
On 12/02/11 10:00, Alex Hunsaker wrote:
> On Sat, Feb 12, 2011 at 01:50, Jan Urbański 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
On Sat, Feb 12, 2011 at 01:50, Jan Urbański 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 " string,
> or P
On 12/02/11 04:12, Alex Hunsaker wrote:
> On Wed, Feb 9, 2011 at 02:10, Jan Urbański 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 i
On Wed, Feb 9, 2011 at 02:10, Jan Urbański 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
http://archives.postgresql.org/pgsql-ha
Robert Haas 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 up. I was j
On Fri, Feb 11, 2011 at 11:22 AM, Alex Hunsaker wrote:
> On Fri, Feb 11, 2011 at 08:45, Robert Haas wrote:
>> On Wed, Feb 9, 2011 at 4:10 AM, Jan Urbański 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:
>>
On Fri, Feb 11, 2011 at 08:45, Robert Haas wrote:
> On Wed, Feb 9, 2011 at 4:10 AM, Jan Urbański 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/Pytho
On Wed, Feb 9, 2011 at 4:10 AM, Jan Urbański 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
http://archives.postgresql.org/pgsql-
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 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 e
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 a/src
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
