From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | ilmari(at)ilmari(dot)org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) |
Cc: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Nikita Glukhov <n(dot)gluhov(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Transform for pl/perl |
Date: | 2018-06-18 21:48:05 |
Message-ID: | 29396.1529358485@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> The remaining unresolved issue in this thread is Ilmari's suggestion
> that we should convert integers to Perl IV (or UV?) if they fit, rather
> than always convert to NV as now.
Oh ... after re-reading the thread I realized there was one other point
that we'd all forgotten about, namely the business about ~0 getting
converted to -1 rather than what Perl interprets it as. Ilmari sent in
a patch for that, against which I'd raised two complaints:
1. Possible compiler complaints about a constant-false comparison,
on machines where type UV is 32 bits.
2. Need for secondary expected-output files, which'd be a pain to
maintain.
I realized that point 1 could be dealt with just by not trying to be
smart, but always using the convert-to-text code path. Given that it
seems to be hard to produce a UV value in Perl, I doubt it is worth
working any harder than that. Also, point 2 could be dealt with in
this perhaps crude way:
-- this might produce either 18446744073709551615 or 4294967295
SELECT testUVToJsonb() IN ('18446744073709551615'::jsonb, '4294967295'::jsonb);
Pushed with those adjustments.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2018-06-18 21:50:44 | Re: Invisible Indexes |
Previous Message | Jaime Casanova | 2018-06-18 21:46:02 | Re: Invisible Indexes |