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
On Fri, 12 Jan 2018 13:33:56 +1300
Thomas Munro wrote:
> On Thu, Dec 7, 2017 at 12:40 AM, Anthony Bykov
> wrote:
> > Hello,
> > fixed the issues:
> > 1. Rising errors when invalid object being transformed.
> > 2. We don't rise the exception when transformin
of numerics you was
talking about. Large numerics are just transformed into "inf" (or
"Inf") and the patch contains such test. But there were no tests with
numerics close to "inf" but not "inf" yet. So, I've added such test.
Also I've fixed the thin
7;t check that.
The problem is that $_ - is a pointer to an array of incoming
parameters. So, if you return $_[0]->{"1"} instead of $_->{"1"}, the
test will return exactly the expected output: {"2":[3,4,5]}
I've tried to test "chop" and even &
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
Hello,
I was trying to review your patch, but I couldn't install it:
pr
* If can not convert if directly, fallback to PLyObject_ToDatum
* to convert it
Maybe it should be something like ("it" instead of second "if")
* If can not convert it directly, fallback to PLyObject_ToDatum
* to convert it
And the same typo is repeated several times in comments.
--
Anthony Bykov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
I thought that plperlu and plperl uses different
interpreters. And if they act identically on same examples - there
is no need in identical tests for them indeed.
Point 2 is fixed in this version of the patch.
Please, find in attachments a new version of the patch.
--
Anthony Bykov
Postgres Prof
pport the full numeric range when
> processing JSONB in SQL, it's just in the PL/Perl transform (and
> possibly PL/Python, I didn't look) we're losing precision.
>
> Perl can also be configured to use long double or __float128 (via
> libquadmath) for its NV type, but
On Fri, 10 Nov 2017 14:40:21 +0100
Pavel Stehule wrote:
> Hi
>
> 2017-10-24 14:27 GMT+02:00 Anthony Bykov :
>
> > There are some moments I should mention:
> > 1. {"1":1}::jsonb is transformed into HV {"1"=>"1"}, while
> > ["
I have some doubts:
1. In file plpy_exec.c there is a typo on line 347:
"... We use the result and resultin[should be here "g"?] variables...
2. In file plpy_cursorobject.c there is a non-volatile variable "elem" used in
try-except construction. Is that OK?
--
Anthony By
b-transformable object is transformed into
string and added to jsonb as a string.
2. couldn't find a solution of working with "inf": this extension
troughs exception if python generates a number called "inf" and returns
it, but if we pass a very large integer into a f
d I had to change behavior of transform when
working with not-representable-in-JSONB format objects - now it will
through an exception. You can find an example in tests.
Please, find the 4-th version of patch in attachments.
--
Anthony Bykov
Postgres Professional: http://www.postgrespro.com
The Russ
Hello,
fixed the issues:
1. Rising errors when invalid object being transformed.
2. We don't rise the exception when transforming range(3) only in
python 2. In third one it is an error.
Please, find the 4-th version of the patch in attachments to this
message. --
Anthony Bykov
Pos
quot;_" redefined #define _(args) args
In file included from ../../src/include/postgres.h:47:0,
from jsonb_plperl.c:12:
../../src/include/c.h:971:0: note: this is the location of the
previous definition #define _(x) gettext(x)
This #undef was
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
> > an
On Sat, 9 Dec 2017 16:57:05 -0500
Peter Eisentraut wrote:
> On 12/6/17 06:40, Anthony Bykov wrote:
> > Hello,
> > fixed the issues:
> > 1. Rising errors when invalid object being transformed.
> > 2. We don't rise the exception when transforming range(3) only in
16 matches
Mail list logo
