Re: Transform for pl/perl
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
> (Ubuntu Trusty on amd64) runs it, it fails like this:
>
> test jsonb_plperl ... FAILED
> test jsonb_plperl_relocatability ... ok
> test jsonb_plperlu... FAILED
> test jsonb_plperlu_relocatability ... ok
>
> = Contents of ./contrib/jsonb_plperl/regression.diffs
> ***
> /home/travis/build/postgresql-cfbot/postgresql/contrib/jsonb_plperl/expected/jsonb_plperl.out
> 2018-01-11 21:46:35.867584467 +
> ---
> /home/travis/build/postgresql-cfbot/postgresql/contrib/jsonb_plperl/results/jsonb_plperl.out
> 2018-01-11 21:55:08.564204175 +
> ***
> *** 89,96
> (1 row)
>
> SELECT testSVToJsonb2('1E+131071');
> ! ERROR: could not transform to type "jsonb"
> ! DETAIL: The type you are trying to transform can't be transformed
> to jsonb CONTEXT: PL/Perl function "testsvtojsonb2"
> SELECT testSVToJsonb2('-1');
>testsvtojsonb2
> --- 89,95
> (1 row)
>
> SELECT testSVToJsonb2('1E+131071');
> ! ERROR: invalid input syntax for type numeric: "inf"
> CONTEXT: PL/Perl function "testsvtojsonb2"
> SELECT testSVToJsonb2('-1');
>testsvtojsonb2
> ==
> ***
> /home/travis/build/postgresql-cfbot/postgresql/contrib/jsonb_plperl/expected/jsonb_plperlu.out
> 2018-01-11 21:46:35.867584467 +
> ---
> /home/travis/build/postgresql-cfbot/postgresql/contrib/jsonb_plperl/results/jsonb_plperlu.out
> 2018-01-11 21:55:08.704204228 +
> ***
> *** 89,96
> (1 row)
>
> SELECT testSVToJsonb2('1E+131071');
> ! ERROR: could not transform to type "jsonb"
> ! DETAIL: The type you are trying to transform can't be transformed
> to jsonb CONTEXT: PL/Perl function "testsvtojsonb2"
> SELECT testSVToJsonb2('-1');
>testsvtojsonb2
> --- 89,95
> (1 row)
>
> SELECT testSVToJsonb2('1E+131071');
> ! ERROR: invalid input syntax for type numeric: "inf"
> CONTEXT: PL/Perl function "testsvtojsonb2"
> SELECT testSVToJsonb2('-1');
>testsvtojsonb2
> ==
>
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.
Thank you again.
--
Anthony Bykov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Companydiff --git a/contrib/Makefile b/contrib/Makefile
index 8046ca4..53d44fe 100644
--- a/contrib/Makefile
+++ b/contrib/Makefile
@@ -75,9 +75,9 @@ ALWAYS_SUBDIRS += sepgsql
endif
ifeq ($(with_perl),yes)
-SUBDIRS += hstore_plperl
+SUBDIRS += hstore_plperl jsonb_plperl
else
-ALWAYS_SUBDIRS += hstore_plperl
+ALWAYS_SUBDIRS += hstore_plperl jsonb_plperl
endif
ifeq ($(with_python),yes)
diff --git a/contrib/jsonb_plperl/Makefile b/contrib/jsonb_plperl/Makefile
new file mode 100644
index 000..cd86553
--- /dev/null
+++ b/contrib/jsonb_plperl/Makefile
@@ -0,0 +1,40 @@
+# contrib/jsonb_plperl/Makefile
+
+MODULE_big = jsonb_plperl
+OBJS = jsonb_plperl.o $(WIN32RES)
+PGFILEDESC = "jsonb_plperl - jsonb transform for plperl"
+
+PG_CPPFLAGS = -I$(top_srcdir)/src/pl/plperl
+
+EXTENSION = jsonb_plperlu jsonb_plperl
+DATA = jsonb_plperlu--1.0.sql jsonb_plperl--1.0.sql
+
+REGRESS = jsonb_plperl jsonb_plperl_relocatability jsonb_plperlu jsonb_plperlu_relocatability
+
+ifdef USE_PGXS
+PG_CONFIG = pg_config
+PGXS := $(shell $(PG_CONFIG) --pgxs)
+include $(PGXS)
+else
+subdir = contrib/jsonb_plperl
+top_builddir = ../..
+include $(top_builddir)/src/Makefile.global
+include $(top_srcdir)/contrib/contrib-global.mk
+endif
+
+# We must link libperl explicitly
+ifeq ($(PORTNAME), win32)
+# these settings are the same as for plperl
+override CPPFLAGS += -DPLPERL_HAVE_UID_GID -Wno-comment
+# ... see silliness in plperl Makefile ...
+SHLIB_LINK += $(sort $(wildcard ../../src/pl/plperl/libperl*.a))
+else
+rpathdir = $(perl_archlibexp)/CORE
+SHLIB_LINK += $(perl_embed_ldflags)
+endif
+
+# As with plperl we need to make sure that the CORE directory is included
+# last, probably because it sometimes contains some header files with names
+# that clash with some of ours, or with some that we include, notably on
+# Windows.
+override CPPFLAGS
Re: Jsonb transform for pl/python
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 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. -- > > Hi Anthony, > > FYI make docs fails: > > json.sgml:584: parser error : Opening and ending tag mismatch: xref > line 581 and para > > ^ > json.sgml:585: parser error : Opening and ending tag mismatch: para > line 575 and sect2 > > ^ > json.sgml:588: parser error : Opening and ending tag mismatch: sect2 > line 572 and sect1 > > ^ > json.sgml:589: parser error : Premature end of data in tag sect1 line > 3 json.sgml:589: parser error : chunk is not well balanced > datatype.sgml:4354: parser error : Failure to process entity json > &json; > ^ > datatype.sgml:4354: parser error : Entity 'json' not defined > &json; > ^ > datatype.sgml:4955: parser error : chunk is not well balanced > postgres.sgml:104: parser error : Failure to process entity datatype > &datatype; > ^ > postgres.sgml:104: parser error : Entity 'datatype' not defined > &datatype; > ^ > Hello, thank you for your message. Fixed it. Here is a new version of the patch. -- Anthony Bykov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company 0001-jsonb_plpython-extension-v5.patch.tar.gz Description: application/gzip
Re: Transform for pl/perl
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 do this in plperl_call_perl_func():
>
> tmp = OutputFunctionCall(&(desc->arg_out_func[i]),
> fcinfo->arg[i]);
> sv = cstr2sv(tmp);
> pfree(tmp)
> [...]
>
> PUSHs(sv_2mortal(sv));
>
> Large numerics won't work as SvNV values, which have to fit in a
> standard double. So I think we should treat them the same way we do
> for plain scalar arguments.
>
> (This also suggests that the tests are a bit deficient in not testing
> jsonb with large numeric values.)
>
> I'm going to set this back to waiting on author pending discussion.
>
>
> cheers
>
> andrew
>
Hello,
thank you for your attention.
I'm sorry, but I couldn't understand what types 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 thing Thomas Munro was talking about.
--
Anthony Bykov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
diff --git a/contrib/Makefile b/contrib/Makefile
index 8046ca4..53d44fe 100644
--- a/contrib/Makefile
+++ b/contrib/Makefile
@@ -75,9 +75,9 @@ ALWAYS_SUBDIRS += sepgsql
endif
ifeq ($(with_perl),yes)
-SUBDIRS += hstore_plperl
+SUBDIRS += hstore_plperl jsonb_plperl
else
-ALWAYS_SUBDIRS += hstore_plperl
+ALWAYS_SUBDIRS += hstore_plperl jsonb_plperl
endif
ifeq ($(with_python),yes)
diff --git a/contrib/jsonb_plperl/Makefile b/contrib/jsonb_plperl/Makefile
new file mode 100644
index 000..cd86553
--- /dev/null
+++ b/contrib/jsonb_plperl/Makefile
@@ -0,0 +1,40 @@
+# contrib/jsonb_plperl/Makefile
+
+MODULE_big = jsonb_plperl
+OBJS = jsonb_plperl.o $(WIN32RES)
+PGFILEDESC = "jsonb_plperl - jsonb transform for plperl"
+
+PG_CPPFLAGS = -I$(top_srcdir)/src/pl/plperl
+
+EXTENSION = jsonb_plperlu jsonb_plperl
+DATA = jsonb_plperlu--1.0.sql jsonb_plperl--1.0.sql
+
+REGRESS = jsonb_plperl jsonb_plperl_relocatability jsonb_plperlu jsonb_plperlu_relocatability
+
+ifdef USE_PGXS
+PG_CONFIG = pg_config
+PGXS := $(shell $(PG_CONFIG) --pgxs)
+include $(PGXS)
+else
+subdir = contrib/jsonb_plperl
+top_builddir = ../..
+include $(top_builddir)/src/Makefile.global
+include $(top_srcdir)/contrib/contrib-global.mk
+endif
+
+# We must link libperl explicitly
+ifeq ($(PORTNAME), win32)
+# these settings are the same as for plperl
+override CPPFLAGS += -DPLPERL_HAVE_UID_GID -Wno-comment
+# ... see silliness in plperl Makefile ...
+SHLIB_LINK += $(sort $(wildcard ../../src/pl/plperl/libperl*.a))
+else
+rpathdir = $(perl_archlibexp)/CORE
+SHLIB_LINK += $(perl_embed_ldflags)
+endif
+
+# As with plperl we need to make sure that the CORE directory is included
+# last, probably because it sometimes contains some header files with names
+# that clash with some of ours, or with some that we include, notably on
+# Windows.
+override CPPFLAGS := $(CPPFLAGS) $(perl_embed_ccflags) -I$(perl_archlibexp)/CORE
diff --git a/contrib/jsonb_plperl/expected/jsonb_plperl.out b/contrib/jsonb_plperl/expected/jsonb_plperl.out
new file mode 100644
index 000..9032f7e
--- /dev/null
+++ b/contrib/jsonb_plperl/expected/jsonb_plperl.out
@@ -0,0 +1,235 @@
+CREATE EXTENSION jsonb_plperl CASCADE;
+NOTICE: installing required extension "plperl"
+-- test hash -> jsonb
+CREATE FUNCTION testHVToJsonb() RETURNS jsonb
+LANGUAGE plperl
+TRANSFORM FOR TYPE jsonb
+AS $$
+$val = {a => 1, b => 'boo', c => undef};
+return $val;
+$$;
+SELECT testHVToJsonb();
+ testhvtojsonb
+-
+ {"a": 1, "b": "boo", "c": null}
+(1 row)
+
+-- test array -> jsonb
+CREATE FUNCTION testAVToJsonb() RETURNS jsonb
+LANGUAGE plperl
+TRANSFORM FOR TYPE jsonb
+AS $$
+$val = [{a => 1, b => 'boo', c => undef}, {d => 2}];
+return $val;
+$$;
+SELECT testAVToJsonb();
+testavtojsonb
+-
+ [{"a": 1, "b": "boo", "c": null}, {"d": 2}]
+(1 row)
+
+-- test scalar -> jsonb
+CREATE FUNCTION testSVToJsonb() RETURNS jsonb
+LANGUAGE plperl
+TRANSFORM FOR TYPE jsonb
+AS $$
+$val = 1;
+return $val;
+$$;
+SELECT testSVToJsonb();
+ testsvtojsonb
+---
+ 1
+(1 row)
+
+-- test blessed scalar -> jsonb
+CREATE FUN
Re: Transform for pl/perl
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.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 Companydiff --git a/contrib/Makefile b/contrib/Makefile
index 8046ca4..53d44fe 100644
--- a/contrib/Makefile
+++ b/contrib/Makefile
@@ -75,9 +75,9 @@ ALWAYS_SUBDIRS += sepgsql
endif
ifeq ($(with_perl),yes)
-SUBDIRS += hstore_plperl
+SUBDIRS += hstore_plperl jsonb_plperl
else
-ALWAYS_SUBDIRS += hstore_plperl
+ALWAYS_SUBDIRS += hstore_plperl jsonb_plperl
endif
ifeq ($(with_python),yes)
diff --git a/contrib/jsonb_plperl/Makefile b/contrib/jsonb_plperl/Makefile
new file mode 100644
index 000..cd86553
--- /dev/null
+++ b/contrib/jsonb_plperl/Makefile
@@ -0,0 +1,40 @@
+# contrib/jsonb_plperl/Makefile
+
+MODULE_big = jsonb_plperl
+OBJS = jsonb_plperl.o $(WIN32RES)
+PGFILEDESC = "jsonb_plperl - jsonb transform for plperl"
+
+PG_CPPFLAGS = -I$(top_srcdir)/src/pl/plperl
+
+EXTENSION = jsonb_plperlu jsonb_plperl
+DATA = jsonb_plperlu--1.0.sql jsonb_plperl--1.0.sql
+
+REGRESS = jsonb_plperl jsonb_plperl_relocatability jsonb_plperlu jsonb_plperlu_relocatability
+
+ifdef USE_PGXS
+PG_CONFIG = pg_config
+PGXS := $(shell $(PG_CONFIG) --pgxs)
+include $(PGXS)
+else
+subdir = contrib/jsonb_plperl
+top_builddir = ../..
+include $(top_builddir)/src/Makefile.global
+include $(top_srcdir)/contrib/contrib-global.mk
+endif
+
+# We must link libperl explicitly
+ifeq ($(PORTNAME), win32)
+# these settings are the same as for plperl
+override CPPFLAGS += -DPLPERL_HAVE_UID_GID -Wno-comment
+# ... see silliness in plperl Makefile ...
+SHLIB_LINK += $(sort $(wildcard ../../src/pl/plperl/libperl*.a))
+else
+rpathdir = $(perl_archlibexp)/CORE
+SHLIB_LINK += $(perl_embed_ldflags)
+endif
+
+# As with plperl we need to make sure that the CORE directory is included
+# last, probably because it sometimes contains some header files with names
+# that clash with some of ours, or with some that we include, notably on
+# Windows.
+override CPPFLAGS := $(CPPFLAGS) $(perl_embed_ccflags) -I$(perl_archlibexp)/CORE
diff --git a/contrib/jsonb_plperl/expected/jsonb_plperl.out b/contrib/jsonb_plperl/expected/jsonb_plperl.out
new file mode 100644
index 000..152e62d
--- /dev/null
+++ b/contrib/jsonb_plperl/expected/jsonb_plperl.out
@@ -0,0 +1,243 @@
+CREATE EXTENSION jsonb_plperl CASCADE;
+NOTICE: installing required extension "plperl"
+-- test hash -> jsonb
+CREATE FUNCTION testHVToJsonb() RETURNS jsonb
+LANGUAGE plperl
+TRANSFORM FOR TYPE jsonb
+AS $$
+$val = {a => 1, b => 'boo', c => undef};
+return $val;
+$$;
+SELECT testHVToJsonb();
+ testhvtojsonb
+-
+ {"a": 1, "b": "boo", "c": null}
+(1 row)
+
+-- test array -> jsonb
+CREATE FUNCTION testAVToJsonb() RETURNS jsonb
+LANGUAGE plperl
+TRANSFORM FOR TYPE jsonb
+AS $$
+$val = [{a => 1, b => 'boo', c => undef}, {d => 2}];
+return $val;
+$$;
+SELECT testAVToJsonb();
+testavtojsonb
+-
+ [{"a": 1, "b": "boo", "c&quo
Re: Optimze usage of immutable functions as relation
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: prepjointree.c: In function ‘pull_up_simple_function’: prepjointree.c:1793:41: error: ‘functions’ undeclared (first use in this function); did you mean ‘PGFunction’? Assert(!contain_vars_of_level((Node *) functions, 0)); Was it a typo? The new status of this patch is: Waiting on Author
Re: [PATCH] Add missing type conversion functions for PL/Python
On Wed, 31 Jan 2018 11:57:12 +0800
Haozhou Wang wrote:
> Hi All,
>
> PL/Python already has different type conversion functions to
> convert PostgreSQL datum to Python object. However, the conversion
> functions from Python object to PostgreSQL datum only has Boolean,
> Bytea and String functions.
>
> In this patch, we add rest of Integer and Float related datatype
> conversion functions
> and can increase the performance of data conversion greatly especially
> when returning a large array.
>
> We did a quick test about the performance of returning array in
> PL/Python:
>
> The following UDF is used for test:
>
> ```
> CREATE OR REPLACE FUNCTION pyoutfloat8(num int) RETURNS float8[] AS $$
> return [x/3.0 for x in range(num)]
> $$ LANGUAGE plpythonu;
> ```
>
> The test command is
>
> ```
> select count(pyoutfloat8(n));
> ```
>
> The count is used for avoid large output, where n is the number of
> element in returned array, and the size is from 1.5k to15m.
>
> Size of Array 1.5k |15k |
> 150k| 1.5m| 15m |
>
> Origin 2.324ms | 19.834ms | 194.991ms
> | 1927.28ms| 19982.1ms |
>
> With this patch 1.168ms | 3.052ms |
> 21.888ms | 213.39ms |2138.5ms |
>
> All test for both PG and PL/Python are passed.
>
> Thanks very much.
>
>
Hello,
sounds like a really nice patch. I've started looking
through the code and noticed a sort of a typos (or I just couldn't
understand what did you mean) in comments.
file "src/pl/plpython/plpy_typeio.c"
the comment is
* 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
Re: Transform for pl/perl
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_FromJsonbValue’:
> jsonb_plperl.c:69:9: warning: ‘result’ may be used uninitialized in
> this function [-Wmaybe-uninitialized]
> return result;
> ^~
> jsonb_plperl.c: In function ‘SV_FromJsonb’:
> jsonb_plperl.c:142:9: warning: ‘result’ may be used uninitialized in
> this function [-Wmaybe-uninitialized]
> return result;
> ^~
>
> 2. bad comment
>
> /*
> * SV_ToJsonbValue
> *
> * Transform Jsonb into SV --- propably reverse direction
> */
>
>
> /*
> * HV_ToJsonbValue
> *
> * Transform Jsonb into SV
> */
>
> /*
> * plperl_to_jsonb(SV *in)
> *
> * Transform Jsonb into SV
> */
>
> 3. Do we need two identical tests fro PLPerl and PLPerlu? Why?
>
> Regards
>
> Pavel
Hello, thanks for reviewing my patch! I really appreciate it.
That warnings are created on purpose - I was trying to prevent the case
when new types are added into pl/perl, but new transform logic was not.
Maybe there is a better way to do it, but right now I'll just add the
"default: pg_unreachable" logic.
About the 3 point - 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 Professional: http://www.postgrespro.com
The Russian Postgres Company
diff --git a/contrib/Makefile b/contrib/Makefile
index 8046ca4..53d44fe 100644
--- a/contrib/Makefile
+++ b/contrib/Makefile
@@ -75,9 +75,9 @@ ALWAYS_SUBDIRS += sepgsql
endif
ifeq ($(with_perl),yes)
-SUBDIRS += hstore_plperl
+SUBDIRS += hstore_plperl jsonb_plperl
else
-ALWAYS_SUBDIRS += hstore_plperl
+ALWAYS_SUBDIRS += hstore_plperl jsonb_plperl
endif
ifeq ($(with_python),yes)
diff --git a/contrib/jsonb_plperl/Makefile b/contrib/jsonb_plperl/Makefile
new file mode 100644
index 000..cd86553
--- /dev/null
+++ b/contrib/jsonb_plperl/Makefile
@@ -0,0 +1,40 @@
+# contrib/jsonb_plperl/Makefile
+
+MODULE_big = jsonb_plperl
+OBJS = jsonb_plperl.o $(WIN32RES)
+PGFILEDESC = "jsonb_plperl - jsonb transform for plperl"
+
+PG_CPPFLAGS = -I$(top_srcdir)/src/pl/plperl
+
+EXTENSION = jsonb_plperlu jsonb_plperl
+DATA = jsonb_plperlu--1.0.sql jsonb_plperl--1.0.sql
+
+REGRESS = jsonb_plperl jsonb_plperl_relocatability jsonb_plperlu jsonb_plperlu_relocatability
+
+ifdef USE_PGXS
+PG_CONFIG = pg_config
+PGXS := $(shell $(PG_CONFIG) --pgxs)
+include $(PGXS)
+else
+subdir = contrib/jsonb_plperl
+top_builddir = ../..
+include $(top_builddir)/src/Makefile.global
+include $(top_srcdir)/contrib/contrib-global.mk
+endif
+
+# We must link libperl explicitly
+ifeq ($(PORTNAME), win32)
+# these settings are the same as for plperl
+override CPPFLAGS += -DPLPERL_HAVE_UID_GID -Wno-comment
+# ... see silliness in plperl Makefile ...
+SHLIB_LINK += $(sort $(wildcard ../../src/pl/plperl/libperl*.a))
+else
+rpathdir = $(perl_archlibexp)/CORE
+SHLIB_LINK += $(perl_embed_ldflags)
+endif
+
+# As with plperl we need to make sure that the CORE directory is included
+# last, probably because it sometimes contains some header files with names
+# that clash with some of ours, or with some that we include, notably on
+# Windows.
+override CPPFLAGS := $(CPPFLAGS) $(perl_embed_ccflags) -I$(perl_archlibexp)/CORE
diff --git a/contrib/jsonb_plperl/expected/jsonb_plperl.out b/contrib/jsonb_plperl/expected/jsonb_plperl.out
new file mode 100644
index 000..152e62d
--- /dev/null
+++ b/contrib/jsonb_plperl/expected/jsonb_plperl.out
@@ -0,0 +1,243 @@
+CREATE EXTENSION jsonb_plperl CASCADE;
+NOTICE: installing required extension "plperl"
+-- test hash -> jsonb
+CREATE FUNCTION testHVToJsonb() RETURNS jsonb
+LANGUAGE plperl
+TRANSFORM FOR TYPE jsonb
+AS $$
+$val = {a => 1, b => 'boo', c => undef};
+return $val;
+$$;
+SELECT testHVToJsonb();
+ testhvtojsonb
+-
+ {"a": 1, "b": "boo", "c": null}
+(1 row)
+
+-- test array -> jsonb
+CREATE FUNCTION testAVToJsonb() RETURNS jsonb
+LANGUAGE plperl
+TRANSFORM FOR TYPE jsonb
+AS $$
+$val = [{a => 1, b => 'boo', c => undef}, {d => 2}];
+return $val;
+$$;
+SELECT testAVToJsonb();
+testavtojsonb
+-
+ [{"a": 1, "b": "boo", "c": null}, {"d": 2}]
+(1 row)
+
+-- test scalar -> jsonb
+CREATE FUNCTION testS
Re: Transform for pl/perl
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 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. > > It means that if you call a jsonb-transforming pl/perl function like > >select somefunc(jsonb '42'); > > it receives not the scalar 42, but reference to a reference to the > scalar (**int instead of an int, in C terms). This is not caught by > the current round-trip tests because the output transform > automatically dereferences any number of references on the way out > again. > > The fix is to reshuffle the newRV() calls in Jsonb_to_SV() and > jsonb_to_plperl(). I am working on a patch (and improved tests) for > this, but have not have had time to finish it yet. I hope be able to > in the next week or so. > > >> 3) jsonb numeric values are passed as perl's NV (floating point) > >> type, losing precision if they're integers that would fit in an IV > >> or UV. > > > > This seems fixable, but perhaps we need to think through whether > > this will result in other strange behaviors. > > Nubers > 2⁵³ are not "interoperable" in the sense of the JSON spec, > because JavaScript only has doubles, but it seems desirable to > preserve whatever precision one reasonably can, and I can't think of > any downsides. We already support 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 I think preserving 64bit integers > when building against a Perl with a 64bit integer type would be > sufficient. > > - ilmari Hello, need any help with the patch? -- Anthony Bykov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
Re: [HACKERS] Transform for pl/perl
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
> > ["1","2"]::jsonb is transformed into AV ["1", "2"]
> >
> > 2. If there is a numeric value appear in jsonb, it will be
> > transformed to SVnv through string (Numeric->String->SV->SVnv). Not
> > the best solution, but as far as I understand this is usual
> > practise in postgresql to serialize Numerics and de-serialize them.
> >
> > 3. SVnv is transformed into jsonb through string
> > (SVnv->String->Numeric).
> >
> > An example may also be helpful to understand extension. So, as an
> > example, function "test" transforms incoming jsonb into perl,
> > transforms it back into jsonb and returns it.
> >
> > create extension jsonb_plperl cascade;
> >
> > create or replace function test(val jsonb)
> > returns jsonb
> > transform for type jsonb
> > language plperl
> > as $$
> > return $_[0];
> > $$;
> >
> > select test('{"1":1,"example": null}'::jsonb);
> >
> >
> I am looking to this patch:
>
> 1. the patch contains some artefacts - look the word "hstore"
>
> 2. I got lot of warnings
>
>
> make[1]: Vstupuje se do adresáře
> „/home/pavel/src/postgresql/contrib/jsonb_plperl“
> gcc -Wall -Wmissing-prototypes -Wpointer-arith
> -Wdeclaration-after-statement -Wendif-labels
> -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing
> -fwrapv -fexcess-precision=standard -g -ggdb -Og -g3
> -fno-omit-frame-pointer -fPIC -I../../src/pl/plperl -I. -I.
> -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:83:9:
> warning: ‘result’ may be used uninitialized in this function
> [-Wmaybe-uninitialized] return (result);
> ^
> jsonb_plperl.c: In function ‘SV_FromJsonb’:
> jsonb_plperl.c:95:10: warning: ‘object’ may be used uninitialized in
> this function [-Wmaybe-uninitialized]
> HV *object;
> ^~
> In file included from /usr/lib64/perl5/CORE/perl.h:5644:0,
> from ../../src/pl/plperl/plperl.h:52,
> from jsonb_plperl.c:17:
> /usr/lib64/perl5/CORE/embed.h:404:19: warning: ‘value’ may be used
> uninitialized in this function [-Wmaybe-uninitialized]
> #define newRV(a) Perl_newRV(aTHX_ a)
>^~
> jsonb_plperl.c:101:10: note: ‘value’ was declared here
> SV *value;
> ^
> gcc -Wall -Wmissing-prototypes -Wpointer-arith
> -Wdeclaration-after-statement -Wendif-labels
> -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing
> -fwrapv -fexcess-precision=standard -g -ggdb -Og -g3
> -fno-omit-frame-pointer -fPIC -shared -o jsonb_plperl.so
> jsonb_plperl.o -L../../src/port -L../../src/common -Wl,--as-needed
> -Wl,-rpath,'/usr/lib64/perl5/CORE',--enable-new-dtags -Wl,-z,relro
> -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
> -fstack-protector-strong -L/usr/local/lib -L/usr/lib64/perl5/CORE
> -lperl -lpthread -lresolv -lnsl -ldl -lm -lcrypt -lutil -lc make[1]:
> Opouští se adresář „/home/pavel/src/postgresql/contrib/jsonb_plperl“
>
> [pavel@nemesis contrib]$ gcc --version
> gcc (GCC) 7.2.1 20170915 (Red Hat 7.2.1-2)
> Copyright (C) 2017 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There
> is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
> PARTICULAR PURPOSE.
>
> 3. regress tests passed
>
> 4. There are not any documentation - probably it should be part of
> PLPerl
>
> 5. The regress tests doesn't coverage other datatypes than numbers. I
> miss boolean, binary, object, ... Maybe using data::dumper or some
> similar can be interesting
>
> Note - it is great extension, I am pleasured so transformations are
> used.
>
> Regards
>
> Pavel
> >
> > --
> > Sent via pgsql-hackers mailing list (pgsql-hack...@postgresql.org)
> > To make changes to your subscription:
> > http://www.postgresql.org/mailpref/pgsql-hackers
> >
Hello,
Thank you for your review. I have fixed most of your comments, except
for the 5-th part, about data::dumper - I just couldn't understand
your point, but I've added more tests with more complex objects if this
helps.
Please, take a look at new patch. You can find it in attachments to
this
Re: Rewriting PL/Python's typeio code
The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: not tested Spec compliant: not tested Documentation:tested, passed Hello, I have checked your patch. Everything looks fine for me, but 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 Bykov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company The new status of this patch is: Waiting on Author
Re: Jsonb transform for pl/python
On Mon, 13 Nov 2017 15:08:16 +
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:tested, passed
>
> Hi Anthony,
>
> Thank you for the new version of the patch! Here is my code review.
>
> 1. In jsonb_plpython2.out:
>
> +CREATE FUNCTION back(val jsonb) RETURNS jsonb
> +LANGUAGE plpython2u
> +TRANSFORM FOR TYPE jsonb
> +as $$
> +return val
> +$$;
> +SELECT back('null'::jsonb);
> + back
> +
> + [null]
> +(1 row)
> +
> +SELECT back('1'::jsonb);
> + back
> +--
> + [1]
> +(1 row)
> +
> +SELECT back('true'::jsonb);
> + back
> +
> + [true]
> +(1 row)
>
> Maybe I'm missing something, but why exactly all JSONB values turn
> into arrays?
>
> 2. Could you please also add tests for some negative and real
> numbers? Also could you check that your code handles numbers like
> MAX_INT, MIN_INT, +/- infinity and NaN properly in both (Python <->
> JSONB) directions?
>
> 3. Handling unicode strings properly is another thing that is worth
> checking.
>
> 4. I think we also need some tests that check the behavior of Python
> -> JSONB conversion when the object contains data that is not
> representable in JSON format, e.g. set(), some custom objects, etc.
>
> 5. PyObject_FromJsonbValue - I realize it's unlikely that the new
> jsonbValue->type will be introduced any time soon. Still I believe
> it's a good practice to add "it should never happen" default case
> that just does elog(ERROR, ...) in case it happens nevertheless.
> Otherwise in this scenario instead of reporting the error the code
> will silently do the wrong thing.
>
> 6. Well, you decided to make the extension non-relocatable. Could you
> at least describe what prevents it to be relocatable or why it's
> meaningless is a comment in .control file? Please note that almost
> all contrib/ extensions are relocatable. I believe your extension
> should be relocatable as well unless there is a good reason why it
> can't.
>
> The new status of this patch is: Waiting on Author
Hi,
thank you for your review. I took your comments into account in the
third version of the patch. In the new version, I've added all the
tests you asked for. The interesting thing is that:
1. set or any other non-jsonb-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 function, it works fine
with the whole number. This situation can be seen in tests.
I've added tests of large numerics which weights quite heavy. So,
please find it in compressed format in attachments.
--
Anthony Bykov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
0001-jsonb_plpython-extension-v3.patch.gz
Description: application/gzip
Re: Transform for pl/perl
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:tested, passed
>
> Hello Anthony,
>
> Great patch! Everything is OK and I almost agree with Pavel.
>
> The only thing that I would like to suggest is to add a little more
> tests for various corner cases. For instance:
>
> 1. Converting in both directions (Perl <-> JSONB) +/- infinity, NaN,
> MAX_INT, MIN_INT.
>
> 2. Converting in both directions strings that contain non-ASCII
> (Russian / Japanese / etc) characters and special characters like \n,
> \t, \.
>
> 3. Make sure that converting Perl objects that are not representable
> in JSONB (blessed hashes, file descriptors, regular expressions, ...)
> doesn't crash everything and shows a reasonable error message.
>
> The new status of this patch is: Waiting on Author
Hello Aleksander,
Thank you for your review.
I've added more tests and 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 Russian Postgres Companydiff --git a/contrib/Makefile b/contrib/Makefile
index 8046ca4..53d44fe 100644
--- a/contrib/Makefile
+++ b/contrib/Makefile
@@ -75,9 +75,9 @@ ALWAYS_SUBDIRS += sepgsql
endif
ifeq ($(with_perl),yes)
-SUBDIRS += hstore_plperl
+SUBDIRS += hstore_plperl jsonb_plperl
else
-ALWAYS_SUBDIRS += hstore_plperl
+ALWAYS_SUBDIRS += hstore_plperl jsonb_plperl
endif
ifeq ($(with_python),yes)
diff --git a/contrib/jsonb_plperl/Makefile b/contrib/jsonb_plperl/Makefile
new file mode 100644
index 000..cd86553
--- /dev/null
+++ b/contrib/jsonb_plperl/Makefile
@@ -0,0 +1,40 @@
+# contrib/jsonb_plperl/Makefile
+
+MODULE_big = jsonb_plperl
+OBJS = jsonb_plperl.o $(WIN32RES)
+PGFILEDESC = "jsonb_plperl - jsonb transform for plperl"
+
+PG_CPPFLAGS = -I$(top_srcdir)/src/pl/plperl
+
+EXTENSION = jsonb_plperlu jsonb_plperl
+DATA = jsonb_plperlu--1.0.sql jsonb_plperl--1.0.sql
+
+REGRESS = jsonb_plperl jsonb_plperl_relocatability jsonb_plperlu jsonb_plperlu_relocatability
+
+ifdef USE_PGXS
+PG_CONFIG = pg_config
+PGXS := $(shell $(PG_CONFIG) --pgxs)
+include $(PGXS)
+else
+subdir = contrib/jsonb_plperl
+top_builddir = ../..
+include $(top_builddir)/src/Makefile.global
+include $(top_srcdir)/contrib/contrib-global.mk
+endif
+
+# We must link libperl explicitly
+ifeq ($(PORTNAME), win32)
+# these settings are the same as for plperl
+override CPPFLAGS += -DPLPERL_HAVE_UID_GID -Wno-comment
+# ... see silliness in plperl Makefile ...
+SHLIB_LINK += $(sort $(wildcard ../../src/pl/plperl/libperl*.a))
+else
+rpathdir = $(perl_archlibexp)/CORE
+SHLIB_LINK += $(perl_embed_ldflags)
+endif
+
+# As with plperl we need to make sure that the CORE directory is included
+# last, probably because it sometimes contains some header files with names
+# that clash with some of ours, or with some that we include, notably on
+# Windows.
+override CPPFLAGS := $(CPPFLAGS) $(perl_embed_ccflags) -I$(perl_archlibexp)/CORE
diff --git a/contrib/jsonb_plperl/expected/jsonb_plperl.out b/contrib/jsonb_plperl/expected/jsonb_plperl.out
new file mode 100644
index 000..b5c0980
--- /dev/null
+++ b/contrib/jsonb_plperl/expected/jsonb_plperl.out
@@ -0,0 +1,239 @@
+CREATE EXTENSION jsonb_plperl CASCADE;
+NOTICE: installing required extension "plperl"
+-- test hash -> jsonb
+CREATE FUNCTION testHVToJsonb() RETURNS jsonb
+LANGUAGE plperl
+TRANSFORM FOR TYPE jsonb
+AS $$
+$val = {a => 1, b => 'boo', c => undef};
+return $val;
+$$;
+SELECT testHVToJsonb();
+ testhvtojsonb
+-
+ {"a": 1, "b": "boo", "c": null}
+(1 row)
+
+-- test array -> jsonb
+CREATE FUNCTION testAVToJsonb() RETURNS jsonb
+LANGUAGE plperl
+TRANSFORM FOR TYPE jsonb
+AS $$
+$val = [{a => 1, b => 'boo', c => undef}, {d => 2}];
+return $val;
+$$;
+SELECT testAVToJsonb();
+testavtojsonb
+-
+ [{"a": 1, "b": "boo", "c": null}, {"d": 2}]
+(1 row)
+
+-- test scalar -> jsonb
+CREATE FUNCTION testSVToJsonb() RETURNS jsonb
+LANGUAGE plperl
+TRANSFORM FOR TYPE jsonb
+AS $$
+$val = 1;
+return $val;
+$$;
+SELECT testSVToJsonb();
+ testsvtojsonb
+---
+ 1
+(1 row)
+
+-- test blessed scalar -> jsonb
+CREATE FUNCTION testBlessedToJsonb() RETURNS jsonb
+LANGUAGE plperl
+TRANSFORM FOR TYPE jsonb
+AS $$
+my $class = shift;
+my $tmp = {
Re: Jsonb transform for pl/python
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 Postgres Professional: http://www.postgrespro.com The Russian Postgres Company 0001-jsonb_plpython-extension-v4.patch.tar.gz Description: application/gzip
Re: Transform for pl/perl
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) conform to style guidelines: errmsg() start with lowercase,
> others are complete phrases (start with uppercase, end with period)
>c) replace
> "The type you was trying to transform can't be represented in
> JSONB" maybe with
> errmsg("could not transform to type \"%s\"", "jsonb"),
> errdetail("The type you are trying to transform can't be
> represented in JSON") d) same errmsg() for the other error; figure
> out suitable errdetail.
>
> 3. whitespace: don't add newlines to while, DirectFunctionCallN,
> pnstrdup.
>
> 4. the "relocatability" test seems pointless to me.
>
> 5. "#undef _" looks bogus. Don't do it.
>
Hello,
thank you for your time.
1. I really think that it might be a good practice to test non ASCII
symbols on platforms where it is possible. Maybe locale-dependent
Makefile? I've already spent pretty much time trying to find possible
solutions and I have no results. So, I've deleted this tests. Maybe
there is a better solution I don't know about?
2. Thank you for this one. Writing those errors were really pain for
me. I've changed those things in new patch.
3. I've fixed all the whitespaces you was talking about in new version
of the patch.
4. The relocatibility test is needed in order to check if patch is
still relocatable. With this test I've tried to prove the code
"relocatable=true" in *.control files. So, I've decided to leave them
in next version of the patch.
5. If I delete #undef _, I will get the warning:
/usr/lib/x86_64-linux-gnu/perl/5.22/CORE/config.h:3094:0:
warning: "_" 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 meant to fix the warning. I hope a new comment next
to #undef contains all the explanations needed.
Please, find a new version of the patch in attachments to this message.
--
Anthony Bykov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Re: Transform for pl/perl
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.
> >
> > 2. error messages
> >a) please use ereport() not elog()
> >b) conform to style guidelines: errmsg() start with lowercase,
> > others are complete phrases (start with uppercase, end with period)
> >c) replace
> > "The type you was trying to transform can't be represented in
> > JSONB" maybe with
> > errmsg("could not transform to type \"%s\"", "jsonb"),
> > errdetail("The type you are trying to transform can't be
> > represented in JSON") d) same errmsg() for the other error; figure
> > out suitable errdetail.
> >
> > 3. whitespace: don't add newlines to while, DirectFunctionCallN,
> > pnstrdup.
> >
> > 4. the "relocatability" test seems pointless to me.
> >
> > 5. "#undef _" looks bogus. Don't do it.
> >
>
> Hello,
> thank you for your time.
>
> 1. I really think that it might be a good practice to test non ASCII
> symbols on platforms where it is possible. Maybe locale-dependent
> Makefile? I've already spent pretty much time trying to find
> possible solutions and I have no results. So, I've deleted this
> tests. Maybe there is a better solution I don't know about?
>
> 2. Thank you for this one. Writing those errors were really pain for
> me. I've changed those things in new patch.
>
> 3. I've fixed all the whitespaces you was talking about in new version
> of the patch.
>
> 4. The relocatibility test is needed in order to check if patch is
> still relocatable. With this test I've tried to prove the code
> "relocatable=true" in *.control files. So, I've decided to leave
> them in next version of the patch.
>
> 5. If I delete #undef _, I will get the warning:
> /usr/lib/x86_64-linux-gnu/perl/5.22/CORE/config.h:3094:0:
> warning: "_" 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 meant to fix the warning. I hope a new comment next
> to #undef contains all the explanations needed.
>
> Please, find a new version of the patch in attachments to this
> message.
>
>
> --
> Anthony Bykov
> Postgres Professional: http://www.postgrespro.com
> The Russian Postgres Company
Forgot the patch.
--
Anthony Bykov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Companydiff --git a/contrib/Makefile b/contrib/Makefile
index 8046ca4..53d44fe 100644
--- a/contrib/Makefile
+++ b/contrib/Makefile
@@ -75,9 +75,9 @@ ALWAYS_SUBDIRS += sepgsql
endif
ifeq ($(with_perl),yes)
-SUBDIRS += hstore_plperl
+SUBDIRS += hstore_plperl jsonb_plperl
else
-ALWAYS_SUBDIRS += hstore_plperl
+ALWAYS_SUBDIRS += hstore_plperl jsonb_plperl
endif
ifeq ($(with_python),yes)
diff --git a/contrib/jsonb_plperl/Makefile b/contrib/jsonb_plperl/Makefile
new file mode 100644
index 000..cd86553
--- /dev/null
+++ b/contrib/jsonb_plperl/Makefile
@@ -0,0 +1,40 @@
+# contrib/jsonb_plperl/Makefile
+
+MODULE_big = jsonb_plperl
+OBJS = jsonb_plperl.o $(WIN32RES)
+PGFILEDESC = "jsonb_plperl - jsonb transform for plperl"
+
+PG_CPPFLAGS = -I$(top_srcdir)/src/pl/plperl
+
+EXTENSION = jsonb_plperlu jsonb_plperl
+DATA = jsonb_plperlu--1.0.sql jsonb_plperl--1.0.sql
+
+REGRESS = jsonb_plperl jsonb_plperl_relocatability jsonb_plperlu jsonb_plperlu_relocatability
+
+ifdef USE_PGXS
+PG_CONFIG = pg_config
+PGXS := $(shell $(PG_CONFIG) --pgxs)
+include $(PGXS)
+else
+subdir = contrib/jsonb_plperl
+top_builddir = ../..
+include $(top_builddir)/src/Makefile.global
+include $(top_srcdir)/contrib/contrib-global.mk
+endif
+
+# We must link libperl explicitly
+ifeq ($(PORTNAME), win32)
+# these settings are the same as for plperl
+override CPPFLAGS += -DPLPERL_HAVE_UID_GID -Wno-comment
+# ... see silliness in plperl Makefile ...
+SHLIB_LINK += $(sort $(wildcard ../../src/pl/plperl/libperl*.a))
+else
+rpathdir = $(perl_archlibexp)/CORE
+SHLIB_LINK += $(perl_embed_ldflags)
+endif
+
+# As with plperl we need to make sure that the CORE directory is included
+# last, probably because it sometimes contains some header files with names
+# that clash with some of ours, or with some that we include, notably on
+# Windows
Re: Jsonb transform for pl/python
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 > > python 2. In third one it is an error. > > > > Please, find the 4-th version of the patch in attachments to this > > message. > > Why not make this part of the plpythonu extension? It doesn't have to > be a separate contrib module. > Hello, I thought about that, but the problem is that there will be no possibilities to create custom transform if we create this extension by default. For example, it is easy to check if we install this extension and try to create new transform: # create extension jsonb_plperl cascade; NOTICE: installing required extension "plperl" CREATE EXTENSION # CREATE TRANSFORM FOR jsonb LANGUAGE plperl ( # FROM SQL WITH FUNCTION jsonb_to_plperl(internal), # TO SQL WITH FUNCTION plperl_to_jsonb(internal) # ); 2017-12-11 10:23:07.507 MSK [19149] ERROR: transform for type jsonb language "plperl" already exists 2017-12-11 10:23:07.507 MSK [19149] STATEMENT: CREATE TRANSFORM FOR jsonb LANGUAGE plperl ( FROM SQL WITH FUNCTION jsonb_to_plperl(internal), TO SQL WITH FUNCTION plperl_to_jsonb(internal) ); ERROR: transform for type jsonb language "plperl" already exists Other types of transforms may be interesting for people when they want to transform the jsonb to certain structures. For example, what if the user wants the parameter to be always array inside the function, while this extension can return integers or strings in some cases. -- Anthony Bykov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
