From: | Szymon Guz <mabewlun(at)gmail(dot)com> |
---|---|
To: | Steve Singer <steve(at)ssinger(dot)info> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] Fix conversion for Decimal arguments in plpython functions |
Date: | 2013-06-26 07:17:51 |
Message-ID: | CAFjNrYufOOZEkv4gvVZUmp=VZBfbYHjG5=fNNqvgj-stODBKWw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 26 June 2013 01:40, Steve Singer <steve(at)ssinger(dot)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 version of the patch addresses the issues I mentioned. Thanks for
> looking into seeing if the performance issue is with our conversions to
> strings or inherit with the python decimal type. I guess we (Postgresql)
> can't do much about it. A runtime switch to use cdecimal if it is
> available is a good idea, but I agree with you that could be a different
> patch.
>
> One minor thing I noticed in this round,
>
> PLy_elog(ERROR, "could not import module 'decimal'");
>
> I think should have "decimal" in double-quotes.
>
> I think this patch is ready for a committer to look at it.
>
> Steve
>
>
>>
>
Hi Steve,
thanks for the review.
I was thinking about speeding up the Decimal conversion using the module
you wrote about. What about trying to import it, if it fails, than trying
to load decimal.Decimal? There will be no warning in logs, just additional
information in documentation that it uses this module if it is available?
thanks,
Szymon
From | Date | Subject | |
---|---|---|---|
Next Message | Robins | 2013-06-26 07:23:30 | Re: [9.4 CF 1] The Commitfest Slacker List |
Previous Message | Dean Rasheed | 2013-06-26 07:03:43 | Re: Review: UNNEST (and other functions) WITH ORDINALITY |