[patch] PL/Python is too lossy with floats

Lists: pgsql-hackers
From: Marko Kreen <markokr(at)gmail(dot)com>
To: Postgres Hackers List <pgsql-hackers(at)postgresql(dot)org>
Subject: [patch] PL/Python is too lossy with floats
Date: 2015-03-03 14:32:16
Message-ID: [email protected]
Views: Whole Thread | Raw Message | Download mbox | Resend email
Lists: pgsql-hackers

PL/Python uses str(v) to convert float data, but is lossy
by design. Only repr(v) is guaranteed to have enough
precision to make floats roundtrip properly:

https://docs.python.org/2/library/functions.html#func-repr
https://docs.python.org/2/library/functions.html#str

Example:

$ python
>>> repr(100100100.654321)
'100100100.654321'
>>> str(100100100.654321)
'100100100.654'

Attached patch uses PyObject_Repr() for float data.

As it's annoying-to-debug problem and the patch is simple,
perhaps it's worth backporting?

--
marko

Attachment Content-Type Size
plpy-float-repr.diff text/x-diff 1.9 KB

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Marko Kreen <markokr(at)gmail(dot)com>, Postgres Hackers List <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [patch] PL/Python is too lossy with floats
Date: 2015-03-11 19:49:50
Message-ID: [email protected]
Views: Whole Thread | Raw Message | Download mbox | Resend email
Lists: pgsql-hackers

On 3/3/15 9:32 AM, Marko Kreen wrote:
> PL/Python uses str(v) to convert float data, but is lossy
> by design. Only repr(v) is guaranteed to have enough
> precision to make floats roundtrip properly:

committed


From: Marko Kreen <markokr(at)gmail(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Postgres Hackers List <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [patch] PL/Python is too lossy with floats
Date: 2015-06-01 09:34:41
Message-ID: CACMqXCKiaYm9iiFgc0SJ2rdgCpHMkaG94mrTfYKWQakdBeMoCQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Lists: pgsql-hackers

On Wed, Mar 11, 2015 at 9:49 PM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> On 3/3/15 9:32 AM, Marko Kreen wrote:
>> PL/Python uses str(v) to convert float data, but is lossy
>> by design. Only repr(v) is guaranteed to have enough
>> precision to make floats roundtrip properly:
>
> committed

In 9.3 and before, numeric is converted to float in PL/Python.

Please reconsider backporting.

--
marko


From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Marko Kreen <markokr(at)gmail(dot)com>
Cc: Postgres Hackers List <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [patch] PL/Python is too lossy with floats
Date: 2015-06-10 02:04:25
Message-ID: [email protected]
Views: Whole Thread | Raw Message | Download mbox | Resend email
Lists: pgsql-hackers

On 6/1/15 5:34 AM, Marko Kreen wrote:
> On Wed, Mar 11, 2015 at 9:49 PM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
>> On 3/3/15 9:32 AM, Marko Kreen wrote:
>>> PL/Python uses str(v) to convert float data, but is lossy
>>> by design. Only repr(v) is guaranteed to have enough
>>> precision to make floats roundtrip properly:
>>
>> committed
>
> In 9.3 and before, numeric is converted to float in PL/Python.
>
> Please reconsider backporting.

It's been like this forever, so I don't think it's appropriate to
backpatch this.


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Marko Kreen <markokr(at)gmail(dot)com>, Postgres Hackers List <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [patch] PL/Python is too lossy with floats
Date: 2015-06-10 02:28:35
Message-ID: [email protected]
Views: Whole Thread | Raw Message | Download mbox | Resend email
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On 6/1/15 5:34 AM, Marko Kreen wrote:
>> Please reconsider backporting.

> It's been like this forever, so I don't think it's appropriate to
> backpatch this.

http://www.postgresql.org/docs/devel/static/plpython-data.html
states in so many words that floats are converted with str().
Presumably this needs an update in HEAD, but I would say that
the current behavior is per specification in all back branches.

regards, tom lane