Thread: [patch] PL/Python is too lossy with floats
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
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
On Wed, Mar 11, 2015 at 9:49 PM, Peter Eisentraut <peter_e@gmx.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
On 6/1/15 5:34 AM, Marko Kreen wrote: > On Wed, Mar 11, 2015 at 9:49 PM, Peter Eisentraut <peter_e@gmx.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.
Peter Eisentraut <peter_e@gmx.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