Re: Jsonb transform for pl/python - Mailing list pgsql-hackers

From Alexander Korotkov
Subject Re: Jsonb transform for pl/python
Date
Msg-id CAPpHfdufV+auHuSChG2og7bjWyLxHwZy8iZSsg0uVkC=+kkqNQ@mail.gmail.com
Whole thread Raw
In response to Re: Jsonb transform for pl/python  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Jul 11, 2018 at 12:30 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> > On 6/23/18 01:44, Nikita Glukhov wrote:
> >> We are simply trying first to convert numeric to int64 if is does not have
> >> digits after the decimal point, and then construct Python Int instead of
> >> Decimal.  Standard Python json.loads() does the same for exact integers.
>
> > We just had a very similar but not identical discussion in the thread
> > about the PL/Perl transforms, where we rejected the proposal.  Other
> > comments on this one?
>
> I can sympathize with the speed concern, but the proposed patch produces
> a functional change (ie, you get a different kind of Python object, with
> different behaviors, in some cases).  That seems to me to be a good reason
> to reject it.

Nevertheless, as Nikita pointed, json.loads() performs the same in
Python.  See an example for python 2.7.10.

>>> import json
>>> type(json.loads('1'))
<type 'int'>
>>> type(json.loads('1.0'))
<type 'float'>

So, from postgres point of view this behavior is wrong.  But on
another hand why don't let python transform to behave like a python?

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company


pgsql-hackers by date:

Previous
From: Dilip Kumar
Date:
Subject: Re: partition pruning doesn't work with IS NULL clause in multikeyrange partition case
Next
From: Ashutosh Bapat
Date:
Subject: Re: Expression errors with "FOR UPDATE" and postgres_fdw withpartition wise join enabled.