On 09.01.2013 21:29, Karl O. Pinc wrote:
On 01/09/2013 01:08:39 PM, Jan Urbański wrote:
I actually still prefer to keep the signatures of
PLy_get_spi_sqlerrcode
and PLy_get_spi_error_data similar, so I'd opt for keeping the patch
as-is :)
I will send it on to a committer.
Looks good to me. C
On 01/09/2013 01:08:39 PM, Jan Urbański wrote:
> > I can see arguments to be made for both sides. I'm asking that you
> > think it through to the extent you deem necessary and make
> > changes or not. At that point it should be ready to send
> > to a committer. (I'll re-test first, if you make
On 12/12/12 20:21, Karl O. Pinc wrote:
There were 2 outstanding issue raised:
Is this useful enough/proceeding in the right direction to commit
now?
Should some of the logic be moved out of a subroutine and into the
calling code?
I can see arguments to be made for both sides. I'm asking
Hi Jan and Oskari,
On 12/12/2012 11:36:54 AM, Jan Urbański wrote:
> On 10/12/12 19:20, Karl O. Pinc wrote:
> > On 12/09/2012 10:33:59 PM, Karl O. Pinc wrote:
> > There were 2 outstanding issue raised:
> >
> > Is this useful enough/proceeding in the right direction to commit
> > now?
>
> I believ
Though not the original patch autor, I did modify and submit it to the
CF app, so I'll reply here :)
On 10/12/12 19:20, Karl O. Pinc wrote:
On 12/09/2012 10:33:59 PM, Karl O. Pinc wrote:
I've gone ahead and signed up to review this patch.
Thanks!
There were 2 outstanding issue raised:
I
On 12/09/2012 10:33:59 PM, Karl O. Pinc wrote:
> Hi,
>
> I don't feel particularly qualified to comment, but in the
> interest of (hopefully) helping with the patch review process
> I'm going to comment anyway.
I've gone ahead and signed up to review this patch.
I can confirm that it compiles ag
Hi,
I don't feel particularly qualified to comment, but in the
interest of (hopefully) helping with the patch review process
I'm going to comment anyway.
(Having written this, I feel decidedly unqualified
to critique so please keep this in mind when
considering my comments.)
On 10/31/2012 04:33:
On 05/11/12 19:07, Jan Urbański wrote:
On 05/11/12 18:35, Robert Haas wrote:
You should probably add this to the next CF so we don't forget about it.
I will, as soon as I recover my community account.
Added as https://commitfest.postgresql.org/action/patch_view?id=971
J
--
Sent via pgsql
On 05/11/12 18:35, Robert Haas wrote:
On Wed, Oct 31, 2012 at 5:33 AM, Jan Urbański wrote:
On 30/10/12 22:06, Oskari Saarenmaa wrote:
PL/Python maps Python SPIError exceptions with 'spidata' attribute into
SQL
errors.
Here's an alternative patch that takes advantage of the already present (
On Wed, Oct 31, 2012 at 5:33 AM, Jan Urbański wrote:
> On 30/10/12 22:06, Oskari Saarenmaa wrote:
>>
>> PL/Python maps Python SPIError exceptions with 'spidata' attribute into
>> SQL
>> errors. PL/Python also creates classes in plpy.spiexceptions for all
>> known
>> errors but does not initialize
On 30/10/12 22:06, Oskari Saarenmaa wrote:
PL/Python maps Python SPIError exceptions with 'spidata' attribute into SQL
errors. PL/Python also creates classes in plpy.spiexceptions for all known
errors but does not initialize their spidata, so when a PL/Python function
raises such an exception it
PL/Python maps Python SPIError exceptions with 'spidata' attribute into SQL
errors. PL/Python also creates classes in plpy.spiexceptions for all known
errors but does not initialize their spidata, so when a PL/Python function
raises such an exception it is not recognized properly and is always
rep
12 matches
Mail list logo
