From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
cc: Nikita Glukhov <n.gluhov@postgrespro.ru>,
        Alexander Korotkov <a.korotkov@postgrespro.ru>,
        Aleksander Alekseev <a.alekseev@postgrespro.ru>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
        Anthony Bykov <a.bykov@postgrespro.ru>
Subject: Re: Jsonb transform for pl/python
In-reply-to: <786ad675-29c5-5acb-9d87-c3609689bf7d@2ndquadrant.com>
References: <20171025145100.3a19933f@anthony-24-g082ur>
 <20180112140425.41174bd3@anthony-24-g082ur>
 <151577178706.20515.9599911730425998398.pgcf@coridan.postgresql.org>
 <b6edf1ab-5440-8798-de08-eb816baf58ba@2ndquadrant.com>
 <f07b3955-e3e7-b410-b4fc-dae290774cf9@postgrespro.ru>
 <84a3eaf4-32f6-d2dd-7139-e9c5dd3fec2d@2ndquadrant.com>
 <c02881c2-26ca-dc53-137c-a1239aa9b8c0@2ndquadrant.com>
 <6001af16-b242-2527-bc7e-84b8a959163b@postgrespro.ru>
 <CAPpHfdtw51jzqyF9GDjL=iCdh2gGALJQ8YygS7uaBxFBoVbdHQ@mail.gmail.com>
 <16593cd6-4200-e2ab-8d2e-58b456986d69@postgrespro.ru>
 <786ad675-29c5-5acb-9d87-c3609689bf7d@2ndquadrant.com>
Comments: In-reply-to Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
	message dated "Wed, 27 Jun 2018 18:58:19 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <31797.1531258190.1@sss.pgh.pa.us>
Date: Tue, 10 Jul 2018 17:29:50 -0400
Message-ID: <31798.1531258190@sss.pgh.pa.us>
Precedence: bulk

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.  The fact that it makes the behavior vary depending on the
local width of "long" is also a problem, although I think that could be
fixed.

More generally, I'd be happier with a patch that sped things up for
non-integers too.  I don't know whether Python exposes enough internals
of type Decimal to make that practical, though.  One idea for doing it at
arm's length is to compute the Decimal value using numeric-digit-at-a-time
arithmetic, roughly

    x := 0;
    foreach(digit, numeric)
        x.fma(10000, digit);
    x.scaleb(appropriate-exponent);

In principle that's probably faster than string conversion, but not
sure by how much.

			regards, tom lane