Re: improve type conversion of SPI_processed in Python
От | Tom Lane |
---|---|
Тема | Re: improve type conversion of SPI_processed in Python |
Дата | |
Msg-id | 10594.1515531250@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | improve type conversion of SPI_processed in Python (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>) |
Ответы |
Re: improve type conversion of SPI_processed in Python
|
Список | pgsql-hackers |
Peter Eisentraut <peter.eisentraut@2ndquadrant.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
В списке pgsql-hackers по дате отправления: