|From:||ilmari(at)ilmari(dot)org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=)|
|To:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Cc:||Peter Eisentraut <peter(dot)eisentraut(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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> ilmari(at)ilmari(dot)org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes:
>> I tried fixing this by adding an 'if (SvUV(in))' clause to
>> SV_to_JsonbValue, but I couldn't find a function to create a numeric
>> value from an uint64. If it's not possible, should we error on UVs
>> greater than PG_INT64_MAX?
> 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.
> Or we could add a not-visible-to-SQL uint8-to-numeric function in
> numeric.c. Not sure if this is enough use-case to justify that
I don't think this one use-case is enough, but it's worth keeping in
mind if it keeps cropping up.
"I use RMS as a guide in the same way that a boat captain would use
a lighthouse. It's good to know where it is, but you generally
don't want to find yourself in the same spot." - Tollef Fog Heen
|Next Message||Alvaro Herrera||2018-04-09 15:04:31||Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)|
|Previous Message||Alexander Korotkov||2018-04-09 14:57:19||Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)|