Re: Transform for pl/perl

On Wed, 31 Jan 2018 13:36:22 +0300
Arthur Zakirov <a(dot)zakirov(at)postgrespro(dot)ru> wrote:

> I've noticed a possible bug:
>
> > + /* json key in v */
> > + key =
> > pstrdup(v.val.string.val);
> > + keyLength =
> > v.val.string.len;
> > + JsonbIteratorNext(&it, &v,
> > true);
>
> I think it is worth to use pnstrdup() here, because v.val.string.val
> is not necessarily null-terminated as the comment says:
>
> > struct JsonbValue
> > ...
> > struct
> > {
> > int len;
> > char *val; /* Not
> > necessarily null-terminated */ }
> > string; /* String primitive type */
>
> Consider an example:
>
> =# CREATE FUNCTION testSVToJsonb3(val jsonb) RETURNS jsonb
> LANGUAGE plperl
> TRANSFORM FOR TYPE jsonb
> AS $$
> return $_->{"1"};
> $$;
>
> =# SELECT testSVToJsonb3('{"1":{"2":[3,4,5]},"2":3}');
> testsvtojsonb3
> ----------------
> (null)
>
> But my perl isn't good, so the example maybe isn't good too.
>

Hello.
Glad you've noticed this. Thank you.

I've fixed this possible bug in the new patch, but your example
can'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 "=~ s/\0$//", but that didn't check
the problem.

--
Anthony Bykov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company