On 28 June 2013 22:29, Claudio Freire klaussfre...@gmail.com wrote:
On Fri, Jun 28, 2013 at 5:14 PM, Steve Singer st...@ssinger.info wrote:
On 06/27/2013 05:04 AM, Szymon Guz wrote:
On 27 June 2013 05:21, Steve Singer st...@ssinger.info
mailto:st...@ssinger.info wrote:
On
On Fri, 2013-06-28 at 22:28 +0200, Szymon Guz wrote:
I agree, we can check both. This is quite a nice patch now, I've reviewed
it, all tests pass, works as expected. I think it is ready for committing.
Committed.
Very nice to get that finally fixed.
--
Sent via pgsql-hackers mailing list
On Fri, 2013-06-28 at 17:29 -0300, Claudio Freire wrote:
Why not forego checking of the type, and instead check the interface?
plpy.info(x.as_tuple())
Should do.
d = decimal.Decimal((0,(3,1,4),-2))
d.as_tuple()
DecimalTuple(sign=0, digits=(3, 1, 4), exponent=-2)
I think that
On Fri, Jul 5, 2013 at 11:47 PM, Peter Eisentraut pete...@gmx.net wrote:
On Fri, 2013-06-28 at 17:29 -0300, Claudio Freire wrote:
Why not forego checking of the type, and instead check the interface?
plpy.info(x.as_tuple())
Should do.
d = decimal.Decimal((0,(3,1,4),-2))
d.as_tuple()
On 06/27/2013 05:04 AM, Szymon Guz wrote:
On 27 June 2013 05:21, Steve Singer st...@ssinger.info
mailto:st...@ssinger.info wrote:
On 06/26/2013 04:47 PM, Szymon Guz wrote:
Hi Steve,
thanks for the changes.
You're idea about common code for decimal and cdecimal is good,
however not
On 28 June 2013 22:14, Steve Singer st...@ssinger.info wrote:
I think the value is more important than the name, I want to the tests to
make sure that the conversion is actually converting properly. With your
method of getting the class name without the module we can have both.
The
On Fri, Jun 28, 2013 at 5:14 PM, Steve Singer st...@ssinger.info wrote:
On 06/27/2013 05:04 AM, Szymon Guz wrote:
On 27 June 2013 05:21, Steve Singer st...@ssinger.info
mailto:st...@ssinger.info wrote:
On 06/26/2013 04:47 PM, Szymon Guz wrote:
Hi Steve,
thanks for the changes.
On 27 June 2013 05:21, Steve Singer st...@ssinger.info wrote:
On 06/26/2013 04:47 PM, Szymon Guz wrote:
Attached patch has all changes against trunk code.
There is added a function for conversion from Postgres numeric to Python
Decimal. The Decimal type is taken from cdecimal.Decimal,
On 26 June 2013 01:40, Steve Singer st...@ssinger.info wrote:
On 06/25/2013 06:42 AM, Szymon Guz wrote:
Hi,
I've attached a new patch. I've fixed all the problems you've found,
except for the efficiency problem, which has been described in previous
email.
thanks,
Szymon
This
The v2 patch does not work for me: regression tests for plpython fail on
the plpython_types test: every numeric is converted to None.
It seems the global decimal ctor is not initialized.
Please find two patches, to be applied on top of the v2 patch: one
initializes the decimal ctor, the other
Thanks Steve, that's exactly what I wanted to send when you sent your
patches :)
I need to figure out why that patch v2 worked for me, I think I made mess
somewhere in my git repo and didn't create the patch properly. Sorry for
that.
Patch is attached, I've also added information about cdecimal
You had a great idea, the time with cdecimal is really great, the
difference on my machine is 64 ms vs 430 ms.
Szymon
It seems like you confused me with steve :)
The patch applies cleanly, and the regression tests pass on python2 when
cdecimal is not installed. When it is, the type info returned for the
converted numeric value is cdecimal.Decimal instead of decimal.Decimal.
The regression tests expected output
On 26 June 2013 12:04, Ronan Dunklau rdunk...@gmail.com wrote:
It seems like you confused me with steve :)
Hi Ronan,
Oh, yes. I'm sorry for that :)
The patch applies cleanly, and the regression tests pass on python2 when
cdecimal is not installed. When it is, the type info returned for the
On 6/26/13 7:03 AM, Szymon Guz wrote:
I've checked the patch, everything looks great.
I've attached it to this email with changed name, just for consistent
naming in commitfest app.
Could the setup of the decimal.Decimal constructor be moved into
PLyDecimal_FromNumeric() and kept in a static
On 26 June 2013 21:59, Peter Eisentraut pete...@gmx.net wrote:
On 6/26/13 7:03 AM, Szymon Guz wrote:
I've checked the patch, everything looks great.
I've attached it to this email with changed name, just for consistent
naming in commitfest app.
Could the setup of the decimal.Decimal
On 26 June 2013 22:08, Szymon Guz mabew...@gmail.com wrote:
On 26 June 2013 21:59, Peter Eisentraut pete...@gmx.net wrote:
On 6/26/13 7:03 AM, Szymon Guz wrote:
I've checked the patch, everything looks great.
I've attached it to this email with changed name, just for consistent
naming in
On 06/26/2013 04:47 PM, Szymon Guz wrote:
Attached patch has all changes against trunk code.
There is added a function for conversion from Postgres numeric to
Python Decimal. The Decimal type is taken from cdecimal.Decimal, if it
is available. It is an external library, quite fast, but
On 25 June 2013 05:16, Steve Singer st...@ssinger.info wrote:
One concern I have is that this patch makes pl/python functions involving
numerics more than 3 times as slow as before.
create temp table b(a numeric);
insert into b select generate_series(1,1);
create or replace function
On 25 June 2013 05:16, Steve Singer st...@ssinger.info wrote:
On 05/28/2013 04:41 PM, Szymon Guz wrote:
Hi,
I've got a patch.
This is for a plpython enhancement.
There is an item at the TODO list http://wiki.postgresql.org/**
Concerning the efficiency problem, it should be noted that the latest 3.3
release of cpython introduces an accelerator for decimal data types, as a
C-module. This module was previously available from the Python package
index at: https://pypi.python.org/pypi/cdecimal/2.2
It may be overkill to try
Well, I really don't like the idea of such a dependency.
However it could be added as configuration option, so you could compile
postgres with e.g. --with-cdecimal, and then it would be user dependent.
Maybe it is a good idea for another patch.
On 25 June 2013 14:23, Ronan Dunklau
On 06/25/2013 06:42 AM, Szymon Guz wrote:
Hi,
I've attached a new patch. I've fixed all the problems you've found,
except for the efficiency problem, which has been described in
previous email.
thanks,
Szymon
This version of the patch addresses the issues I mentioned. Thanks for
On 05/28/2013 04:41 PM, Szymon Guz wrote:
Hi,
I've got a patch.
This is for a plpython enhancement.
There is an item at the TODO list
http://wiki.postgresql.org/wiki/Todo#Server-Side_Languages
Fix loss of information during conversion of numeric type to Python
float
This patch uses a
Hi,
I've got a patch.
This is for a plpython enhancement.
There is an item at the TODO list
http://wiki.postgresql.org/wiki/Todo#Server-Side_Languages
Fix loss of information during conversion of numeric type to Python float
This patch uses a decimal.Decimal type from Python standard library
25 matches
Mail list logo
