Re: [HACKERS] pl/python improvements

2010-12-24 Thread James William Pye
On Dec 23, 2010, at 3:38 AM, Jan Urbański wrote: > Oh, didn't know that. I see that it does some more fancy things, like > defining a inheritance hierarchy for these exceptions and adding some > more into the mix. Right, there were some cases that appeared to benefit from larger buckets than what

Re: [HACKERS] pl/python improvements

2010-12-23 Thread Jan Urbański
On 23/12/10 12:16, Marti Raudsepp wrote: > On Thu, Dec 23, 2010 at 04:08, Jan Urbański wrote: >> * providing custom exceptions for SPI errors, so you can catch only >> UniqueViolations and not have to muck around with SQLCODE > > py-postgresql already has a mapping from error codes to Python > e

Re: [HACKERS] pl/python improvements

2010-12-23 Thread Marti Raudsepp
On Thu, Dec 23, 2010 at 04:08, Jan Urbański wrote: >  * providing custom exceptions for SPI errors, so you can catch only > UniqueViolations and not have to muck around with SQLCODE py-postgresql already has a mapping from error codes to Python exceptions. I think it makes sense to re-use that, i

Re: [HACKERS] pl/python improvements

2010-12-22 Thread Jan Urbański
On 08/12/10 22:41, Peter Eisentraut wrote: > On tis, 2010-12-07 at 23:56 +0100, Jan Urbański wrote: >> Peter suggested having a mail/patch per feature and the way I intend >> to do that is instead of having a dozen branches, have one and after >> I'm done rebase it interactively to produce incremen

Re: [HACKERS] pl/python improvements

2010-12-08 Thread Peter Eisentraut
On tis, 2010-12-07 at 23:56 +0100, Jan Urbański wrote: > Peter suggested having a mail/patch per feature and the way I intend > to do that is instead of having a dozen branches, have one and after > I'm done rebase it interactively to produce incremental patches that > apply to master, each one imp

Re: [HACKERS] pl/python improvements

2010-12-07 Thread Jan Urbański
On 07/12/10 23:00, Andrew Dunstan wrote: > On 12/07/2010 04:50 PM, Peter Eisentraut wrote: >> >>> The code is on https://github.com/wulczer/postgres, in the plpython >>> branch. I'll be rebasing it regularly, so don't be surprised by commit >>> hashes changing. >> I think rebasing published reposit

Re: [HACKERS] pl/python improvements

2010-12-07 Thread Andrew Dunstan
On 12/07/2010 04:50 PM, Peter Eisentraut wrote: The code is on https://github.com/wulczer/postgres, in the plpython branch. I'll be rebasing it regularly, so don't be surprised by commit hashes changing. I think rebasing published repositories isn't encouraged. Indeed. See

Re: [HACKERS] pl/python improvements

2010-12-07 Thread Peter Eisentraut
On tis, 2010-12-07 at 20:17 +0100, Jan Urbański wrote: > no, no patch(es) yet. I'm going through plpython.c trying as best I can > to improve things there. I'll have a patch (or patches) ready for the > January commitfest, but I thought I'd open up a discussion already to > spare me having to redo

Re: [HACKERS] pl/python improvements

2010-12-07 Thread Jan Urbański
On 07/12/10 21:33, Andres Freund wrote: > On Tuesday 07 December 2010 20:17:57 Jan Urbański wrote: >> * execute SPI calls in a subtransaction, report errors back to Python >> as exceptions that can be caught etc. > Youre doing that unconditionally? I think the performance impact of this will > be

Re: [HACKERS] pl/python improvements

2010-12-07 Thread Andres Freund
On Tuesday 07 December 2010 20:17:57 Jan Urbański wrote: > Hi, > > no, no patch(es) yet. I'm going through plpython.c trying as best I can > to improve things there. I'll have a patch (or patches) ready for the > January commitfest, but I thought I'd open up a discussion already to > spare me havi

[HACKERS] pl/python improvements

2010-12-07 Thread Jan Urbański
Hi, no, no patch(es) yet. I'm going through plpython.c trying as best I can to improve things there. I'll have a patch (or patches) ready for the January commitfest, but I thought I'd open up a discussion already to spare me having to redo features because the way I attacked the problem is a dead