From: Tom Lane <tgl@sss.pgh.pa.us>
To: ilmari@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=)
cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
        Pavel Stehule <pavel.stehule@gmail.com>,
        Nikita Glukhov <n.gluhov@postgrespro.ru>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Transform for pl/perl
In-reply-to: <d8jefjojudc.fsf@dalvik.ping.uio.no>
References: <20171127132439.23dc26ef@anthony-24-g082ur>
 <20171201184921.27he6vbp62yegpvm@alvherre.pgsql>
 <20171207125455.39067aa7@anthony-24-g082ur>
 <20171207125602.5326f103@anthony-24-g082ur>
 <CAEepm=02=Ya7p=-X5Of=JD-+9+bmmwnpd9nr8AeVnOopB6Y+NQ@mail.gmail.com>
 <20180112114739.6a9f0d4c@anthony-24-g082ur>
 <20180131103621.GA19345@zakirov.localdomain>
 <20180215125313.290468ae@anthony-24-g082ur>
 <CAFj8pRCYBPFGZG5LHdfY1Ej+a_9sb3ugyDkUaJGD37UjpRpA8Q@mail.gmail.com>
 <20180312110821.29c80420@anthony-24-g082ur>
 <CAFj8pRDaTYHD30CP8u2v_wwsJfxFBfthcNEp_KgEOHVN0gUfAw@mail.gmail.com>
 <505345c5-0159-077d-f64e-60afb01e5fbe@postgrespro.ru>
 <CAFj8pRB1mLEvmnhRL9HheF6yeKPvuzBf2tQ=s+2QXGpnCJdbqQ@mail.gmail.com>
 <26a0840a-6b09-44fc-9e4e-8200c1887882@2ndquadrant.com>
 <d8jtvskjzzs.fsf@dalvik.ping.uio.no> <11284.1523282666@sss.pgh.pa.us>
 <d8jefjojudc.fsf@dalvik.ping.uio.no>
Comments: In-reply-to ilmari@ilmari.org (Dagfinn Ilmari
 =?utf-8?Q?Manns=C3=A5ker?=)
	message dated "Mon, 09 Apr 2018 16:02:23 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <15074.1523287460.1@sss.pgh.pa.us>
Date: Mon, 09 Apr 2018 11:24:20 -0400
Message-ID: <15075.1523287460@sss.pgh.pa.us>
Precedence: bulk

ilmari@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> I think you'd have to convert to text and back.  That's kind of icky,
>> but it beats failing.

> I had a look, and that's what the PL/Python transform does.  Attached is
> a patch that does that for PL/Perl too, but only if the value is
> actually > PG_INT64_MAX.

> The secondary output files are for Perls with 32bit IV/UV types, but I
> haven't been able to test them, since Debian's Perl uses 64bit integers
> even on 32bit platforms.

Ugh.  I really don't want to maintain a separate expected-file for this,
especially not if it's going to be hard to test.  Can we choose another
way of exercising the code path?

Another issue with this code as written is that on 32-bit-UV platforms,
at least some vompilers will give warnings about the constant-false
predicate.  Not sure about a good solution for that.  Maybe it's a
sufficient reason to invent uint8_numeric so we don't need a range check.

			regards, tom lane