Re: improve type conversion of SPI_processed in Python

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: improve type conversion of SPI_processed in Python
Date: 2018-01-09 20:54:10
Message-ID: 10594.1515531250@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
> Here is a patch to improves how PL/Python deals with very large values
> of SPI_processed. The previous code converts anything that does not fit
> into a C long into a Python float. But Python long has unlimited
> precision, so we should be using that instead. And in Python 3, int and
> long as the same, so there is no need to deal with any variations anymore.

I took a quick look at this. +1 for returning Python long all the time,
but I wonder why the Python version dependency. Our existing function
PLyLong_FromInt64() believes that PyLong_FromLongLong is unconditionally
available. I'd be inclined to code PLyObject_FromUint64() as an exact
analog of PLyLong_FromInt64(), ie

/* on 32 bit platforms "unsigned long" may be too small */
if (sizeof(uint64) > sizeof(unsigned long))
return PyLong_FromUnsignedLongLong(DatumGetUInt64(d));
else
return PyLong_FromUnsignedLong(DatumGetUInt64(d));

and let Python worry about how to optimize the conversion.

So far as I can tell from
https://docs.python.org/2/c-api/long.html
these functions are available as far back as we could need.
If the buildfarm tells us otherwise, we could deal with it then.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Walter Cai 2018-01-09 20:58:11 Re:
Previous Message Andrew Dunstan 2018-01-09 20:44:03 Re: [HACKERS] SQL/JSON in PostgreSQL