Re: Transform for pl/perl

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-07 17:52:49
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

ilmari(at)ilmari(dot)org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes:
> Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> 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 understand it. So far this is only a claim by one
>> person. I haven't seen anything conclusive about whether there is an
>> actual issue.

> It's not just how things are passed internally, but how they are passed
> to pl/perl functions with a jsonb transform: JSON scalar values at the
> top level (strings, numbers, booleans, null) get passed as a reference
> to a reference to the value, e.g. \\42 instead of 42. The reason the
> current tests don't pick this up is that they don't check the value
> inside the pl/perl functions, only that they roundtrip back to jsonb,
> and the plperl to jsonb transform recursively dereferences references.

Yeah, the reason this is important is that it affects what the plperl
function body sees.

> Another side effect of the recursive dereferencing is that returning
> undef from the perl function returns an SQL NULL while returning a
> reference to undef (\undef) returns a jsonb null.

Hm, I think you're blaming the wrong moving part there. The way the
transform logic is set up (e.g., in plperl_sv_to_datum()), it's
impossible for a transform function to return a SQL null; the decision by
plperl_sv_to_datum as to whether or not the output will be a SQL null is
final. (Perhaps that was a mistake, but changing the transform function
API seems like a rather Big Deal.) 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's a good idea, but I tend to the view that it is.
Right now the case produces an error, and not even a very sane one:

regression=# create function foo() returns int language plperlu
regression-# as '\undef';
regression=# select foo();
ERROR: PL/Perl function must return reference to hash or array
CONTEXT: PL/Perl function "foo"

so there's not really a compatibility break if we redefine it.

regards, tom lane

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2018-06-07 18:20:10 Re: computing completion tag is expensive for pgbench -S -M prepared
Previous Message Teodor Sigaev 2018-06-07 16:22:13 Re: POC: GROUP BY optimization