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, namel
ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes:
> [ 0001-Fix-excess-enreferencing-in-plperl-jsonb-transform.patch ]
I tested this a bit more thoroughly by dint of applying Data::Dumper
to the Perl values, and found that we were still getting extra references
to sub-objects, f
On 2018-Jun-08, Tom Lane wrote:
> I wrote:
> > I'm inclined to think that auto-dereference is indeed a good idea,
> > and am tempted to go make that change to make all this consistent.
> > Comments?
>
> Here's a draft patch for that. I ended up only changing
> plperl_sv_to_datum. There is maybe
I wrote:
> I'm inclined to think that auto-dereference is indeed a good idea,
> and am tempted to go make that change to make all this consistent.
> Comments?
Here's a draft patch for that. I ended up only changing
plperl_sv_to_datum. There is maybe a case for doing something
similar in plperl_r
I wrote:
> ... So if we think that \undef ought to
> produce a SQL null, the thing to do is move the dereferencing loop to
> the beginning of plperl_sv_to_datum, and then \undef would produce NULL
> whether this transform is installed or not. I don't have a well-informed
> opinion on whether that'
ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes:
> Peter Eisentraut writes:
>> The way I understand it, it's only how things are passed around
>> internally. Nothing is noticeable externally, and so there is no
>> backward compatibility issue.
>>
>> At least that's how I und
Peter Eisentraut writes:
> On 6/6/18 12:14, Alvaro Herrera wrote:
>> On 2018-May-17, Peter Eisentraut wrote:
>>
>>> The items that are still open from the original email are:
>>>
>>> 2) jsonb scalar values are passed to the plperl function wrapped in not
>>>one, but _two_ layers of reference
On 6/6/18 12:14, Alvaro Herrera wrote:
> On 2018-May-17, Peter Eisentraut wrote:
>
>> The items that are still open from the original email are:
>>
>> 2) jsonb scalar values are passed to the plperl function wrapped in not
>>one, but _two_ layers of references
>>
>> 3) jsonb numeric values are
On 2018-May-17, Peter Eisentraut wrote:
> The items that are still open from the original email are:
>
> 2) jsonb scalar values are passed to the plperl function wrapped in not
>one, but _two_ layers of references
>
> 3) jsonb numeric values are passed as perl's NV (floating point) type,
>
On Wed, 02 May 2018 17:41:38 +0100
ilm...@ilmari.org (Dagfinn Ilmari Mannsåker) wrote:
> Peter Eisentraut writes:
>
> > These two items are now outstanding:
> >
> > On 4/10/18 07:33, Dagfinn Ilmari Mannsåker wrote:
> >> 2) jsonb scalar values are passed to the plperl function wrapped
> >> in n
On 5/17/18 17:11, Alvaro Herrera wrote:
> This is still listed as an open item, though the patch proposed by Peter
> upthread has been committed. If I understand correctly, ilmari was
> going to propose another patch. Or is the right course of action to set
> the open item as resolved?
The items
Alvaro Herrera writes:
> This is still listed as an open item, though the patch proposed by Peter
> upthread has been committed. If I understand correctly, ilmari was
> going to propose another patch. Or is the right course of action to set
> the open item as resolved?
AIUI, ilmari complained a
Hello
This is still listed as an open item, though the patch proposed by Peter
upthread has been committed. If I understand correctly, ilmari was
going to propose another patch. Or is the right course of action to set
the open item as resolved?
On 2018-May-02, Dagfinn Ilmari Mannsåker wrote:
Peter Eisentraut writes:
> These two items are now outstanding:
>
> On 4/10/18 07:33, Dagfinn Ilmari Mannsåker wrote:
>> 2) jsonb scalar values are passed to the plperl function wrapped in not
>>one, but _two_ layers of references
>
> I don't understand this one, or why it's a problem, or wha
These two items are now outstanding:
On 4/10/18 07:33, Dagfinn Ilmari Mannsåker wrote:
> 2) jsonb scalar values are passed to the plperl function wrapped in not
>one, but _two_ layers of references
I don't understand this one, or why it's a problem, or what to do about it.
> 3) jsonb numeric
On 4/29/18 14:28, Tom Lane wrote:
> Peter Eisentraut writes:
>> On 4/24/18 14:31, Andrew Dunstan wrote:
>>> There is the routine IsValidJsonNumber that helps - see among others
>>> hstore_io.c for an example use.
>
>> I would need something like that taking a double/float8 input. But I
>> think
Peter Eisentraut writes:
> On 4/24/18 14:31, Andrew Dunstan wrote:
>> There is the routine IsValidJsonNumber that helps - see among others
>> hstore_io.c for an example use.
> I would need something like that taking a double/float8 input. But I
> think there is no such shortcut available, so I j
On 4/24/18 14:31, Andrew Dunstan wrote:
> There is the routine IsValidJsonNumber that helps - see among others
> hstore_io.c for an example use.
I would need something like that taking a double/float8 input. But I
think there is no such shortcut available, so I just wrote out the tests
for isinf
On 04/24/2018 12:17 PM, Peter Eisentraut wrote:
> On 4/10/18 10:31, Dagfinn Ilmari Mannsåker wrote:
>> Also, it doesn't parse back in as jsonb either:
>>
>> =# select jsonbnan()::text::json;
>> ERROR: invalid input syntax for type json
>> DETAIL: Token "NaN" is invalid.
>> CONTE
On 4/10/18 10:31, Dagfinn Ilmari Mannsåker wrote:
> Also, it doesn't parse back in as jsonb either:
>
> =# select jsonbnan()::text::json;
> ERROR: invalid input syntax for type json
> DETAIL: Token "NaN" is invalid.
> CONTEXT: JSON data, line 1: NaN
>
> And it's inconsistent wi
On 4/10/18 07:33, Dagfinn Ilmari Mannsåker wrote:
> 1) both the jsonb_plperl and jsonb_plperlu extensions contain the SQL
>functions jsonb_to_plperl and plperl_to_jsonb, so can't be installed
>simultaneously
>
> 2) jsonb scalar values are passed to the plperl function wrapped in not
>o
ilm...@ilmari.org (Dagfinn Ilmari Mannsåker) writes:
> Tom Lane writes:
>
>> ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes:
>>> While playing around some more with the extension, I discoverered a few
>>> more issues:
>>> ...
>>> 4) SV_to_JsonbValue() throws an error for inf
Tom Lane writes:
> ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes:
>> While playing around some more with the extension, I discoverered a few
>> more issues:
>> ...
>> 4) SV_to_JsonbValue() throws an error for infinite NVs, but not NaNs
>
> The others sound like bugs, but th
ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes:
> While playing around some more with the extension, I discoverered a few
> more issues:
> ...
> 4) SV_to_JsonbValue() throws an error for infinite NVs, but not NaNs
The others sound like bugs, but that one's intentional, since
Tom Lane writes:
> ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes:
>> Tom Lane 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 patc
ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes:
> Tom Lane 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/Per
Tom Lane writes:
> ilm...@ilmari.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
>>
ilm...@ilmari.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
Peter Eisentraut writes:
> On 3/15/18 03:46, Pavel Stehule wrote:
>> It looks well
>>
>> the patch has tests and doc,
>> there are not any warnings or compilation issues
>> all tests passed
>>
>> I'll mark this patch as ready for commiter
>
> committed
I played around with this a bit, and noti
On 3/15/18 03:46, Pavel Stehule wrote:
> It looks well
>
> the patch has tests and doc,
> there are not any warnings or compilation issues
> all tests passed
>
> I'll mark this patch as ready for commiter
committed
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Develop
Hi
2018-03-13 15:50 GMT+01:00 Nikita Glukhov :
> Hi.
>
> I have reviewed this patch too. Attached new version with v8-v9 delta-patch.
>
> Here is my changes:
>
> * HV_ToJsonbValue():
> - addded missing hv_iterinit()
> - used hv_iternextsv() instead of hv_iternext(), HeSVKEY_force(), HeV
Hi.
I have reviewed this patch too. Attached new version with v8-v9 delta-patch.
Here is my changes:
* HV_ToJsonbValue():
- addded missing hv_iterinit()
- used hv_iternextsv() instead of hv_iternext(), HeSVKEY_force(), HeVAL()
* SV_ToJsonbValue():
- added recursive dereferencing
2018-03-12 9:08 GMT+01:00 Anthony Bykov :
> On Mon, 5 Mar 2018 14:03:37 +0100
> Pavel Stehule wrote:
>
> > Hi
> >
> > I am looking on this patch. I found few issues:
> >
> > 1. compile warning
> >
> > I../../src/include -D_GNU_SOURCE -I/usr/include/libxml2
> > -I/usr/lib64/perl5/CORE -c -o json
On Mon, 5 Mar 2018 14:03:37 +0100
Pavel Stehule wrote:
> Hi
>
> I am looking on this patch. I found few issues:
>
> 1. compile warning
>
> I../../src/include -D_GNU_SOURCE -I/usr/include/libxml2
> -I/usr/lib64/perl5/CORE -c -o jsonb_plperl.o jsonb_plperl.c
> jsonb_plperl.c: In function ‘SV_F
Hi
I am looking on this patch. I found few issues:
1. compile warning
I../../src/include -D_GNU_SOURCE -I/usr/include/libxml2
-I/usr/lib64/perl5/CORE -c -o jsonb_plperl.o jsonb_plperl.c
jsonb_plperl.c: In function ‘SV_FromJsonbValue’:
jsonb_plperl.c:69:9: warning: ‘result’ may be used uninitia
On Wed, 31 Jan 2018 13:36:22 +0300
Arthur Zakirov wrote:
> I've noticed a possible bug:
>
> > + /* json key in v */
> > + key =
> > pstrdup(v.val.string.val);
> > + keyLength =
> > v.val.string.
On Sat, 13 Jan 2018 09:29:46 -0500
Andrew Dunstan wrote:
> There's a bit of an impedance mismatch and inconsistency here. I think
> we need to deal with json scalars (particularly numerics) the same way
> we do for plain scalar arguments. We don't convert a numeric argument
> to and SvNV. We just
Hello,
On Fri, Jan 12, 2018 at 11:47:39AM +0300, Anthony Bykov wrote:
> Hello, thank you for your message.
> The problem was that different perl compilers uses different infinity
> representations. Some of them use "Inf" others - use "inf". So, in
> attachments there is a new version of the patch.
On Fri, Jan 12, 2018 at 9:47 PM, Anthony Bykov wrote:
> On Fri, 12 Jan 2018 15:19:26 +1300
> Thomas Munro wrote:
> Hello, thank you for your message.
> The problem was that different perl compilers uses different infinity
> representations. Some of them use "Inf" others - use "inf". So, in
> atta
On 01/12/2018 03:47 AM, Anthony Bykov wrote:
>
> The problem was that different perl compilers uses different infinity
> representations. Some of them use "Inf" others - use "inf". So, in
> attachments there is a new version of the patch.
>
There's a bit of an impedance mismatch and inconsisten
On Fri, 12 Jan 2018 15:19:26 +1300
Thomas Munro wrote:
> On Thu, Dec 7, 2017 at 10:56 PM, Anthony Bykov
> wrote:
> >> Please, find a new version of the patch in attachments to this
> >> message.
>
> Hi again Anthony,
>
> I wonder why make check passes for me on my Mac, but when Travis CI
> (
On Thu, Dec 7, 2017 at 10:56 PM, Anthony Bykov wrote:
>> Please, find a new version of the patch in attachments to this
>> message.
Hi again Anthony,
I wonder why make check passes for me on my Mac, but when Travis CI
(Ubuntu Trusty on amd64) runs it, it fails like this:
test jsonb_plperl
On 12/1/17 13:15, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Dec 1, 2017 at 12:30 AM, Michael Paquier
>> wrote:
>>> Patch moved to CF 2018-01. Perhaps a committer will look at it at some
>>> point.
>
>> FWIW, although I like the idea, I'm not going to work on the patch. I
>> like Perl, b
On Thu, 7 Dec 2017 12:54:55 +0300
Anthony Bykov wrote:
> On Fri, 1 Dec 2017 15:49:21 -0300
> Alvaro Herrera wrote:
>
> > A few very minor comments while quickly paging through:
> >
> > 1. non-ASCII tests are going to cause problems in one platform or
> > another. Please don't include that one
On Fri, 1 Dec 2017 15:49:21 -0300
Alvaro Herrera wrote:
> A few very minor comments while quickly paging through:
>
> 1. non-ASCII tests are going to cause problems in one platform or
> another. Please don't include that one.
>
> 2. error messages
>a) please use ereport() not elog()
>b
On 12/01/2017 11:37 AM, Robert Haas wrote:
> On Fri, Dec 1, 2017 at 12:30 AM, Michael Paquier
> wrote:
>> On Tue, Nov 28, 2017 at 5:14 PM, Aleksander Alekseev
>> wrote:
>>> The new status of this patch is: Ready for Committer
>> Patch moved to CF 2018-01. Perhaps a committer will look at it at
A few very minor comments while quickly paging through:
1. non-ASCII tests are going to cause problems in one platform or
another. Please don't include that one.
2. error messages
a) please use ereport() not elog()
b) conform to style guidelines: errmsg() start with lowercase, others
Robert Haas writes:
> On Fri, Dec 1, 2017 at 12:30 AM, Michael Paquier
> wrote:
>> Patch moved to CF 2018-01. Perhaps a committer will look at it at some point.
> FWIW, although I like the idea, I'm not going to work on the patch. I
> like Perl, but I neither know its internals nor use plperl.
On Fri, Dec 1, 2017 at 12:30 AM, Michael Paquier
wrote:
> On Tue, Nov 28, 2017 at 5:14 PM, Aleksander Alekseev
> wrote:
>> The new status of this patch is: Ready for Committer
>
> Patch moved to CF 2018-01. Perhaps a committer will look at it at some point.
FWIW, although I like the idea, I'm no
On Tue, Nov 28, 2017 at 5:14 PM, Aleksander Alekseev
wrote:
> The new status of this patch is: Ready for Committer
Patch moved to CF 2018-01. Perhaps a committer will look at it at some point.
--
Michael
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
Looks good to me.
The new status of this patch is: Ready for
On Wed, 15 Nov 2017 08:58:54 +
Aleksander Alekseev wrote:
> The following review has been posted through the commitfest
> application: make installcheck-world: tested, passed
> Implements feature: tested, passed
> Spec compliant: tested, passed
> Documentation:tes
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
Hello Anthony,
Great patch! Everything is OK and I almost ag
53 matches
Mail list logo
