agora inbox for [email protected]help / color / mirror / Atom feed
[PATCH 9/9] Ignore correlation for new BRIN opclasses 15+ messages / 6 participants [nested] [flat]
* [PATCH 9/9] Ignore correlation for new BRIN opclasses @ 2020-09-12 13:07 Tomas Vondra <[email protected]> 0 siblings, 0 replies; 15+ messages in thread From: Tomas Vondra @ 2020-09-12 13:07 UTC (permalink / raw) The new BRIN opclasses (bloom and minmax-multi) are less sensitive to poorly correlated data, so just assume the data is perfectly correlated during costing. Author: Tomas Vondra <[email protected]> Discussion: https://postgr.es/m/[email protected] --- src/backend/access/brin/brin_bloom.c | 1 + src/backend/access/brin/brin_minmax_multi.c | 1 + src/backend/utils/adt/selfuncs.c | 19 ++++++++++++++++++- src/include/access/brin_internal.h | 3 +++ 4 files changed, 23 insertions(+), 1 deletion(-) diff --git a/src/backend/access/brin/brin_bloom.c b/src/backend/access/brin/brin_bloom.c index b54b963f87..af87737ae0 100644 --- a/src/backend/access/brin/brin_bloom.c +++ b/src/backend/access/brin/brin_bloom.c @@ -410,6 +410,7 @@ brin_bloom_opcinfo(PG_FUNCTION_ARGS) result = palloc0(MAXALIGN(SizeofBrinOpcInfo(1)) + sizeof(BloomOpaque)); + result->oi_ignore_correlation = true; result->oi_nstored = 1; result->oi_regular_nulls = true; result->oi_opaque = (BloomOpaque *) diff --git a/src/backend/access/brin/brin_minmax_multi.c b/src/backend/access/brin/brin_minmax_multi.c index c77c207e94..28a6a85b5a 100644 --- a/src/backend/access/brin/brin_minmax_multi.c +++ b/src/backend/access/brin/brin_minmax_multi.c @@ -1798,6 +1798,7 @@ brin_minmax_multi_opcinfo(PG_FUNCTION_ARGS) result = palloc0(MAXALIGN(SizeofBrinOpcInfo(1)) + sizeof(MinmaxMultiOpaque)); + result->oi_ignore_correlation = true; result->oi_nstored = 1; result->oi_regular_nulls = true; result->oi_opaque = (MinmaxMultiOpaque *) diff --git a/src/backend/utils/adt/selfuncs.c b/src/backend/utils/adt/selfuncs.c index 47ca4ddbb5..bf40f9ce32 100644 --- a/src/backend/utils/adt/selfuncs.c +++ b/src/backend/utils/adt/selfuncs.c @@ -98,6 +98,7 @@ #include <math.h> #include "access/brin.h" +#include "access/brin_internal.h" #include "access/brin_page.h" #include "access/gin.h" #include "access/table.h" @@ -7352,7 +7353,8 @@ brincostestimate(PlannerInfo *root, IndexPath *path, double loop_count, double minimalRanges; double estimatedRanges; double selec; - Relation indexRel; + Relation indexRel = NULL; + TupleDesc tupdesc = NULL; ListCell *l; VariableStatData vardata; @@ -7374,6 +7376,7 @@ brincostestimate(PlannerInfo *root, IndexPath *path, double loop_count, */ indexRel = index_open(index->indexoid, NoLock); brinGetStats(indexRel, &statsData); + tupdesc = RelationGetDescr(indexRel); index_close(indexRel, NoLock); /* work out the actual number of ranges in the index */ @@ -7407,6 +7410,17 @@ brincostestimate(PlannerInfo *root, IndexPath *path, double loop_count, { IndexClause *iclause = lfirst_node(IndexClause, l); AttrNumber attnum = index->indexkeys[iclause->indexcol]; + FmgrInfo *opcInfoFn; + BrinOpcInfo *opcInfo; + Form_pg_attribute attr = TupleDescAttr(tupdesc, iclause->indexcol); + bool ignore_correlation; + + opcInfoFn = index_getprocinfo(indexRel, iclause->indexcol + 1, BRIN_PROCNUM_OPCINFO); + + opcInfo = (BrinOpcInfo *) + DatumGetPointer(FunctionCall1(opcInfoFn, attr->atttypid)); + + ignore_correlation = opcInfo->oi_ignore_correlation; /* attempt to lookup stats in relation for this index column */ if (attnum != 0) @@ -7477,6 +7491,9 @@ brincostestimate(PlannerInfo *root, IndexPath *path, double loop_count, if (sslot.nnumbers > 0) varCorrelation = Abs(sslot.numbers[0]); + if (ignore_correlation) + varCorrelation = 1.0; + if (varCorrelation > *indexCorrelation) *indexCorrelation = varCorrelation; diff --git a/src/include/access/brin_internal.h b/src/include/access/brin_internal.h index fdaff42722..5fbf8cf9c7 100644 --- a/src/include/access/brin_internal.h +++ b/src/include/access/brin_internal.h @@ -30,6 +30,9 @@ typedef struct BrinOpcInfo /* Regular processing of NULLs in BrinValues? */ bool oi_regular_nulls; + /* Ignore correlation during cost estimation */ + bool oi_ignore_correlation; + /* Opaque pointer for the opclass' private use */ void *oi_opaque; -- 2.26.2 --------------22A4B241170149838D4D1F8F-- ^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Bytea PL/Perl transform @ 2024-01-06 15:51 vignesh C <[email protected]> 0 siblings, 1 reply; 15+ messages in thread From: vignesh C @ 2024-01-06 15:51 UTC (permalink / raw) To: Ivan Panchenko <[email protected]>; +Cc: Tom Lane <[email protected]>; Peter Eisentraut <[email protected]>; [email protected]; Greg Sabino Mullane <[email protected]> On Fri, 21 Jul 2023 at 02:59, Ivan Panchenko <[email protected]> wrote: > > Friday, 14 July 2023, 23:27 +03:00 от Tom Lane <[email protected]>: > > =?UTF-8?B?SXZhbiBQYW5jaGVua28=?= <[email protected]> writes: > > Четверг, 6 июля 2023, 14:48 +03:00 от Peter Eisentraut < [email protected] >: > >> If the transform deals with a built-in type, then they should just be > >> added to the respective pl extension directly. > > > The new extension bytea_plperl can be easily moved into plperl now, but what should be do with the existing ones, namely jsonb_plperl and bool_plperl ? > > If we leave them where they are, it would be hard to explain why some transforms are inside plperl while other ones live separately. If we move them into plperl also, wouldn’t it break some compatibility? > > It's kind of a mess, indeed. But I think we could make plperl 1.1 > contain the additional transforms and just tell people they have > to drop the obsolete extensions before they upgrade to 1.1. > Fortunately, it doesn't look like functions using a transform > have any hard dependency on the transform, so "drop extension > jsonb_plperl" followed by "alter extension plperl update" should > work without cascading to all your plperl functions. > > Having said that, we'd still be in the position of having to > explain why some transforms are packaged with plperl and others > not. The distinction between built-in and contrib types might > be obvious to us hackers, but I bet a lot of users see it as > pretty artificial. So maybe the existing packaging design is > fine and we should just look for a way to reduce the code > duplication. > > The code duplication between different transforms is not in C code, but mostly in copy-pasted Makefile, *.control, *.sql and meson-build. These files could be generated from some universal templates. But, keeping in mind Windows compatibility and presence of three build system, this hardly looks like a simplification. > Probably at present time it would be better to keep the existing code duplication until plperl 1.1. > Nevertheless, dealing with code duplication is a wider task than the bytea transform, so let me suggest to keep this extension in the present form. If we decide what to do with the duplication, it would be another patch. > > The mesonified and rebased version of the transform patch is attached. The patch needs to be rebased as these changes are not required anymore: diff --git a/src/tools/msvc/Mkvcbuild.pm b/src/tools/msvc/Mkvcbuild.pm index 9e05eb91b1..ec0a3f8097 100644 --- a/src/tools/msvc/Mkvcbuild.pm +++ b/src/tools/msvc/Mkvcbuild.pm @@ -43,7 +43,7 @@ my $contrib_extralibs = { 'libpq_pipeline' => ['ws2_32.lib'] }; my $contrib_extraincludes = {}; my $contrib_extrasource = {}; my @contrib_excludes = ( - 'bool_plperl', 'commit_ts', + 'bool_plperl', 'bytea_plperl', 'commit_ts', 'hstore_plperl', 'hstore_plpython', 'intagg', 'jsonb_plperl', 'jsonb_plpython', 'ltree_plpython', @@ -791,6 +791,9 @@ sub mkvcbuild my $bool_plperl = AddTransformModule( 'bool_plperl', 'contrib/bool_plperl', 'plperl', 'src/pl/plperl'); + my $bytea_plperl = AddTransformModule( + 'bytea_plperl', 'contrib/bytea_plperl', + 'plperl', 'src/pl/plperl'); Regards, Vignesh ^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Bytea PL/Perl transform @ 2024-01-30 12:51 Pavel Stehule <[email protected]> parent: vignesh C <[email protected]> 0 siblings, 1 reply; 15+ messages in thread From: Pavel Stehule @ 2024-01-30 12:51 UTC (permalink / raw) To: vignesh C <[email protected]>; +Cc: Ivan Panchenko <[email protected]>; Tom Lane <[email protected]>; Peter Eisentraut <[email protected]>; [email protected]; Greg Sabino Mullane <[email protected]> Hi so 6. 1. 2024 v 16:51 odesílatel vignesh C <[email protected]> napsal: > On Fri, 21 Jul 2023 at 02:59, Ivan Panchenko <[email protected]> wrote: > > > > Friday, 14 July 2023, 23:27 +03:00 от Tom Lane <[email protected]>: > > > > =?UTF-8?B?SXZhbiBQYW5jaGVua28=?= <[email protected]> writes: > > > Четверг, 6 июля 2023, 14:48 +03:00 от Peter Eisentraut < > [email protected] >: > > >> If the transform deals with a built-in type, then they should just be > > >> added to the respective pl extension directly. > > > > > The new extension bytea_plperl can be easily moved into plperl now, > but what should be do with the existing ones, namely jsonb_plperl and > bool_plperl ? > > > If we leave them where they are, it would be hard to explain why some > transforms are inside plperl while other ones live separately. If we move > them into plperl also, wouldn’t it break some compatibility? > > > > It's kind of a mess, indeed. But I think we could make plperl 1.1 > > contain the additional transforms and just tell people they have > > to drop the obsolete extensions before they upgrade to 1.1. > > Fortunately, it doesn't look like functions using a transform > > have any hard dependency on the transform, so "drop extension > > jsonb_plperl" followed by "alter extension plperl update" should > > work without cascading to all your plperl functions. > > > > Having said that, we'd still be in the position of having to > > explain why some transforms are packaged with plperl and others > > not. The distinction between built-in and contrib types might > > be obvious to us hackers, but I bet a lot of users see it as > > pretty artificial. So maybe the existing packaging design is > > fine and we should just look for a way to reduce the code > > duplication. > > > > The code duplication between different transforms is not in C code, but > mostly in copy-pasted Makefile, *.control, *.sql and meson-build. These > files could be generated from some universal templates. But, keeping in > mind Windows compatibility and presence of three build system, this hardly > looks like a simplification. > > Probably at present time it would be better to keep the existing code > duplication until plperl 1.1. > > Nevertheless, dealing with code duplication is a wider task than the > bytea transform, so let me suggest to keep this extension in the present > form. If we decide what to do with the duplication, it would be another > patch. > > > > The mesonified and rebased version of the transform patch is attached. > > The patch needs to be rebased as these changes are not required anymore: > diff --git a/src/tools/msvc/Mkvcbuild.pm b/src/tools/msvc/Mkvcbuild.pm > index 9e05eb91b1..ec0a3f8097 100644 > --- a/src/tools/msvc/Mkvcbuild.pm > +++ b/src/tools/msvc/Mkvcbuild.pm > @@ -43,7 +43,7 @@ my $contrib_extralibs = { 'libpq_pipeline' => > ['ws2_32.lib'] }; > my $contrib_extraincludes = {}; > my $contrib_extrasource = {}; > my @contrib_excludes = ( > - 'bool_plperl', 'commit_ts', > + 'bool_plperl', 'bytea_plperl', 'commit_ts', > 'hstore_plperl', 'hstore_plpython', > 'intagg', 'jsonb_plperl', > 'jsonb_plpython', 'ltree_plpython', > @@ -791,6 +791,9 @@ sub mkvcbuild > my $bool_plperl = AddTransformModule( > 'bool_plperl', 'contrib/bool_plperl', > 'plperl', 'src/pl/plperl'); > + my $bytea_plperl = AddTransformModule( > + 'bytea_plperl', 'contrib/bytea_plperl', > + 'plperl', 'src/pl/plperl'); > > Regards, > Vignesh > > > I am checking this patch, it looks well. All tests passed. I am sending a cleaned patch. I did minor formatting cleaning. I inserted perl reference support - hstore_plperl and json_plperl does it. +<->/* Dereference references recursively. */ +<->while (SvROK(in)) +<-><-->in = SvRV(in); Regards Pavel Attachments: [text/x-patch] 0001-supports-bytea-transformation-for-plperl.patch (14.4K, ../../CAFj8pRB24y1VPNbB3Ej5UK+3-Qp7-TxYtFKdJj6dwqZVAim7=A@mail.gmail.com/3-0001-supports-bytea-transformation-for-plperl.patch) download | inline diff: From 340b945f06335088d22280755923e2c719e4b598 Mon Sep 17 00:00:00 2001 From: "[email protected]" <[email protected]> Date: Tue, 30 Jan 2024 10:31:00 +0100 Subject: [PATCH] supports bytea transformation for plperl --- contrib/Makefile | 4 +- contrib/bytea_plperl/.gitignore | 4 ++ contrib/bytea_plperl/Makefile | 39 ++++++++++++++ contrib/bytea_plperl/bytea_plperl--1.0.sql | 19 +++++++ contrib/bytea_plperl/bytea_plperl.c | 48 +++++++++++++++++ contrib/bytea_plperl/bytea_plperl.control | 7 +++ contrib/bytea_plperl/bytea_plperlu--1.0.sql | 19 +++++++ contrib/bytea_plperl/bytea_plperlu.control | 6 +++ .../bytea_plperl/expected/bytea_plperl.out | 36 +++++++++++++ .../bytea_plperl/expected/bytea_plperlu.out | 36 +++++++++++++ contrib/bytea_plperl/meson.build | 51 +++++++++++++++++++ contrib/bytea_plperl/sql/bytea_plperl.sql | 22 ++++++++ contrib/bytea_plperl/sql/bytea_plperlu.sql | 22 ++++++++ contrib/meson.build | 1 + doc/src/sgml/plperl.sgml | 16 ++++++ 15 files changed, 328 insertions(+), 2 deletions(-) create mode 100644 contrib/bytea_plperl/.gitignore create mode 100644 contrib/bytea_plperl/Makefile create mode 100644 contrib/bytea_plperl/bytea_plperl--1.0.sql create mode 100644 contrib/bytea_plperl/bytea_plperl.c create mode 100644 contrib/bytea_plperl/bytea_plperl.control create mode 100644 contrib/bytea_plperl/bytea_plperlu--1.0.sql create mode 100644 contrib/bytea_plperl/bytea_plperlu.control create mode 100644 contrib/bytea_plperl/expected/bytea_plperl.out create mode 100644 contrib/bytea_plperl/expected/bytea_plperlu.out create mode 100644 contrib/bytea_plperl/meson.build create mode 100644 contrib/bytea_plperl/sql/bytea_plperl.sql create mode 100644 contrib/bytea_plperl/sql/bytea_plperlu.sql diff --git a/contrib/Makefile b/contrib/Makefile index da4e2316a3..56c628df00 100644 --- a/contrib/Makefile +++ b/contrib/Makefile @@ -77,9 +77,9 @@ ALWAYS_SUBDIRS += sepgsql endif ifeq ($(with_perl),yes) -SUBDIRS += bool_plperl hstore_plperl jsonb_plperl +SUBDIRS += bool_plperl bytea_plperl hstore_plperl jsonb_plperl else -ALWAYS_SUBDIRS += bool_plperl hstore_plperl jsonb_plperl +ALWAYS_SUBDIRS += bool_plperl bytea_plperl hstore_plperl jsonb_plperl endif ifeq ($(with_python),yes) diff --git a/contrib/bytea_plperl/.gitignore b/contrib/bytea_plperl/.gitignore new file mode 100644 index 0000000000..5dcb3ff972 --- /dev/null +++ b/contrib/bytea_plperl/.gitignore @@ -0,0 +1,4 @@ +# Generated subdirectories +/log/ +/results/ +/tmp_check/ diff --git a/contrib/bytea_plperl/Makefile b/contrib/bytea_plperl/Makefile new file mode 100644 index 0000000000..1814d2f418 --- /dev/null +++ b/contrib/bytea_plperl/Makefile @@ -0,0 +1,39 @@ +# contrib/bytea_plperl/Makefile + +MODULE_big = bytea_plperl +OBJS = \ + $(WIN32RES) \ + bytea_plperl.o +PGFILEDESC = "bytea_plperl - bytea transform for plperl" + +PG_CPPFLAGS = -I$(top_srcdir)/src/pl/plperl + +EXTENSION = bytea_plperlu bytea_plperl +DATA = bytea_plperlu--1.0.sql bytea_plperl--1.0.sql + +REGRESS = bytea_plperl bytea_plperlu + +ifdef USE_PGXS +PG_CONFIG = pg_config +PGXS := $(shell $(PG_CONFIG) --pgxs) +include $(PGXS) +else +subdir = contrib/bytea_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_INTERNAL += $(sort $(wildcard ../../src/pl/plperl/libperl*.a)) +else +rpathdir = $(perl_archlibexp)/CORE +SHLIB_LINK += $(perl_embed_ldflags) +endif + +# As with plperl we need to include the perl_includespec directory last. +override CPPFLAGS := $(CPPFLAGS) $(perl_embed_ccflags) $(perl_includespec) diff --git a/contrib/bytea_plperl/bytea_plperl--1.0.sql b/contrib/bytea_plperl/bytea_plperl--1.0.sql new file mode 100644 index 0000000000..6544b2ac85 --- /dev/null +++ b/contrib/bytea_plperl/bytea_plperl--1.0.sql @@ -0,0 +1,19 @@ +/* contrib/bytea_plperl/bytea_plperl--1.0.sql */ + +-- complain if script is sourced in psql, rather than via CREATE EXTENSION +\echo Use "CREATE EXTENSION bytea_plperl" to load this file. \quit + +CREATE FUNCTION bytea_to_plperl(val internal) RETURNS internal +LANGUAGE C STRICT IMMUTABLE +AS 'MODULE_PATHNAME'; + +CREATE FUNCTION plperl_to_bytea(val internal) RETURNS bytea +LANGUAGE C STRICT IMMUTABLE +AS 'MODULE_PATHNAME'; + +CREATE TRANSFORM FOR bytea LANGUAGE plperl ( + FROM SQL WITH FUNCTION bytea_to_plperl(internal), + TO SQL WITH FUNCTION plperl_to_bytea(internal) +); + +COMMENT ON TRANSFORM FOR bytea LANGUAGE plperl IS 'transform between bytea and Perl'; diff --git a/contrib/bytea_plperl/bytea_plperl.c b/contrib/bytea_plperl/bytea_plperl.c new file mode 100644 index 0000000000..3a421b02f7 --- /dev/null +++ b/contrib/bytea_plperl/bytea_plperl.c @@ -0,0 +1,48 @@ +/* + * contrib/bytea_plperl/bytea_plperl.c + */ + +#include "postgres.h" + +#include "fmgr.h" +#include "plperl.h" +#include "varatt.h" + +PG_MODULE_MAGIC; + +PG_FUNCTION_INFO_V1(bytea_to_plperl); +PG_FUNCTION_INFO_V1(plperl_to_bytea); + +Datum +bytea_to_plperl(PG_FUNCTION_ARGS) +{ + dTHX; + bytea *in = PG_GETARG_BYTEA_PP(0); + + return PointerGetDatum(newSVpvn_flags((char *) VARDATA_ANY(in), + VARSIZE_ANY_EXHDR(in), 0 )); +} + +Datum +plperl_to_bytea(PG_FUNCTION_ARGS) +{ + dTHX; + bytea *result; + STRLEN len; + char *ptr; + SV *in; + + in = (SV *) PG_GETARG_POINTER(0); + + /* Dereference references recursively. */ + while (SvROK(in)) + in = SvRV(in); + + ptr = SvPVbyte(in, len); + + result = palloc(VARHDRSZ + len ); + SET_VARSIZE(result, VARHDRSZ + len ); + memcpy(VARDATA_ANY(result), ptr,len ); + + PG_RETURN_BYTEA_P(result); +} diff --git a/contrib/bytea_plperl/bytea_plperl.control b/contrib/bytea_plperl/bytea_plperl.control new file mode 100644 index 0000000000..9ff0f2a8dd --- /dev/null +++ b/contrib/bytea_plperl/bytea_plperl.control @@ -0,0 +1,7 @@ +# bytea_plperl extension +comment = 'transform between bytea and plperl' +default_version = '1.0' +module_pathname = '$libdir/bytea_plperl' +relocatable = true +trusted = true +requires = 'plperl' diff --git a/contrib/bytea_plperl/bytea_plperlu--1.0.sql b/contrib/bytea_plperl/bytea_plperlu--1.0.sql new file mode 100644 index 0000000000..d43e8fbaf4 --- /dev/null +++ b/contrib/bytea_plperl/bytea_plperlu--1.0.sql @@ -0,0 +1,19 @@ +/* contrib/bytea_plperl/bytea_plperlu--1.0.sql */ + +-- complain if script is sourced in psql, rather than via CREATE EXTENSION +\echo Use "CREATE EXTENSION bytea_plperlu" to load this file. \quit + +CREATE FUNCTION bytea_to_plperlu(val internal) RETURNS internal +LANGUAGE C STRICT IMMUTABLE +AS 'MODULE_PATHNAME', 'bytea_to_plperl'; + +CREATE FUNCTION plperlu_to_bytea(val internal) RETURNS bytea +LANGUAGE C STRICT IMMUTABLE +AS 'MODULE_PATHNAME', 'plperl_to_bytea'; + +CREATE TRANSFORM FOR bytea LANGUAGE plperlu ( + FROM SQL WITH FUNCTION bytea_to_plperlu(internal), + TO SQL WITH FUNCTION plperlu_to_bytea(internal) +); + +COMMENT ON TRANSFORM FOR bytea LANGUAGE plperlu IS 'transform between bytea and Perl'; diff --git a/contrib/bytea_plperl/bytea_plperlu.control b/contrib/bytea_plperl/bytea_plperlu.control new file mode 100644 index 0000000000..96cc8c35fb --- /dev/null +++ b/contrib/bytea_plperl/bytea_plperlu.control @@ -0,0 +1,6 @@ +# bytea_plperlu extension +comment = 'transform between bytea and plperlu' +default_version = '1.0' +module_pathname = '$libdir/bytea_plperl' +relocatable = true +requires = 'plperlu' diff --git a/contrib/bytea_plperl/expected/bytea_plperl.out b/contrib/bytea_plperl/expected/bytea_plperl.out new file mode 100644 index 0000000000..eb6fceb9e0 --- /dev/null +++ b/contrib/bytea_plperl/expected/bytea_plperl.out @@ -0,0 +1,36 @@ +CREATE EXTENSION bytea_plperl CASCADE; +NOTICE: installing required extension "plperl" +CREATE FUNCTION cat_bytea(bytea) RETURNS bytea LANGUAGE plperl + TRANSFORM FOR TYPE bytea + AS $$ + return $_[0]; + $$; +SELECT data = cat_bytea(data) + FROM ( + SELECT decode(repeat(unnest(ARRAY[ 'a','abc', 'abcd', 'abcdefgh\000ijkl12' , '爱' ]), 10000), 'escape') data + ) line; + ?column? +---------- + t + t + t + t + t +(5 rows) + +CREATE FUNCTION perl_inverse_bytes(bytea) RETURNS bytea +TRANSFORM FOR TYPE bytea +AS $$ + return join '', reverse split('', $_[0]); +$$ LANGUAGE plperl; +SELECT 'ξενία'::bytea, perl_inverse_bytes('ξενία'::bytea); + bytea | perl_inverse_bytes +------------------------+------------------------ + \xcebeceb5cebdceafceb1 | \xb1ceafcebdceb5cebece +(1 row) + +DROP EXTENSION plperl CASCADE; +NOTICE: drop cascades to 3 other objects +DETAIL: drop cascades to extension bytea_plperl +drop cascades to function cat_bytea(bytea) +drop cascades to function perl_inverse_bytes(bytea) diff --git a/contrib/bytea_plperl/expected/bytea_plperlu.out b/contrib/bytea_plperl/expected/bytea_plperlu.out new file mode 100644 index 0000000000..4b69eaffb1 --- /dev/null +++ b/contrib/bytea_plperl/expected/bytea_plperlu.out @@ -0,0 +1,36 @@ +CREATE EXTENSION bytea_plperlu CASCADE; +NOTICE: installing required extension "plperlu" +CREATE FUNCTION cat_bytea(bytea) RETURNS bytea LANGUAGE plperlu + TRANSFORM FOR TYPE bytea + AS $$ + return $_[0]; + $$; +SELECT data = cat_bytea(data) + FROM ( + SELECT decode(repeat(unnest(ARRAY[ 'a','abc', 'abcd', 'abcdefgh\000ijkl12' , '爱' ]), 10000), 'escape') data + ) line; + ?column? +---------- + t + t + t + t + t +(5 rows) + +CREATE FUNCTION perlu_inverse_bytes(bytea) RETURNS bytea +TRANSFORM FOR TYPE bytea +AS $$ + return join '', reverse split('', $_[0]); +$$ LANGUAGE plperlu; +SELECT 'ξενία'::bytea, perlu_inverse_bytes('ξενία'::bytea); + bytea | perlu_inverse_bytes +------------------------+------------------------ + \xcebeceb5cebdceafceb1 | \xb1ceafcebdceb5cebece +(1 row) + +DROP EXTENSION plperlu CASCADE; +NOTICE: drop cascades to 3 other objects +DETAIL: drop cascades to extension bytea_plperlu +drop cascades to function cat_bytea(bytea) +drop cascades to function perlu_inverse_bytes(bytea) diff --git a/contrib/bytea_plperl/meson.build b/contrib/bytea_plperl/meson.build new file mode 100644 index 0000000000..3c438c2175 --- /dev/null +++ b/contrib/bytea_plperl/meson.build @@ -0,0 +1,51 @@ +# Copyright (c) 2023, PostgreSQL Global Development Group + +if not perl_dep.found() + subdir_done() +endif + +bytea_plperl_sources = files( + 'bytea_plperl.c', +) + +if host_system == 'windows' + bytea_plperl_sources += rc_lib_gen.process(win32ver_rc, extra_args: [ + '--NAME', 'bytea_plperl', + '--FILEDESC', 'bytea_plperl - bytea transform for plperl',]) +endif + +bytea_plperl = shared_module('bytea_plperl', + bytea_plperl_sources, + include_directories: [plperl_inc], + kwargs: contrib_mod_args + { + 'dependencies': [perl_dep, contrib_mod_args['dependencies']], + 'install_rpath': ':'.join(mod_install_rpaths + ['@0@/CORE'.format(archlibexp)]), + 'build_rpath': '@0@/CORE'.format(archlibexp), + }, +) +contrib_targets += bytea_plperl + +install_data( + 'bytea_plperl.control', + 'bytea_plperl--1.0.sql', + kwargs: contrib_data_args, +) + +install_data( + 'bytea_plperlu.control', + 'bytea_plperlu--1.0.sql', + kwargs: contrib_data_args, +) + + +tests += { + 'name': 'bytea_plperl', + 'sd': meson.current_source_dir(), + 'bd': meson.current_build_dir(), + 'regress': { + 'sql': [ + 'bytea_plperl', + 'bytea_plperlu', + ], + }, +} diff --git a/contrib/bytea_plperl/sql/bytea_plperl.sql b/contrib/bytea_plperl/sql/bytea_plperl.sql new file mode 100644 index 0000000000..67dfc973c6 --- /dev/null +++ b/contrib/bytea_plperl/sql/bytea_plperl.sql @@ -0,0 +1,22 @@ +CREATE EXTENSION bytea_plperl CASCADE; + +CREATE FUNCTION cat_bytea(bytea) RETURNS bytea LANGUAGE plperl + TRANSFORM FOR TYPE bytea + AS $$ + return $_[0]; + $$; + +SELECT data = cat_bytea(data) + FROM ( + SELECT decode(repeat(unnest(ARRAY[ 'a','abc', 'abcd', 'abcdefgh\000ijkl12' , '爱' ]), 10000), 'escape') data + ) line; + +CREATE FUNCTION perl_inverse_bytes(bytea) RETURNS bytea +TRANSFORM FOR TYPE bytea +AS $$ + return join '', reverse split('', $_[0]); +$$ LANGUAGE plperl; + +SELECT 'ξενία'::bytea, perl_inverse_bytes('ξενία'::bytea); + +DROP EXTENSION plperl CASCADE; diff --git a/contrib/bytea_plperl/sql/bytea_plperlu.sql b/contrib/bytea_plperl/sql/bytea_plperlu.sql new file mode 100644 index 0000000000..5e47788a73 --- /dev/null +++ b/contrib/bytea_plperl/sql/bytea_plperlu.sql @@ -0,0 +1,22 @@ +CREATE EXTENSION bytea_plperlu CASCADE; + +CREATE FUNCTION cat_bytea(bytea) RETURNS bytea LANGUAGE plperlu + TRANSFORM FOR TYPE bytea + AS $$ + return $_[0]; + $$; + +SELECT data = cat_bytea(data) + FROM ( + SELECT decode(repeat(unnest(ARRAY[ 'a','abc', 'abcd', 'abcdefgh\000ijkl12' , '爱' ]), 10000), 'escape') data + ) line; + +CREATE FUNCTION perlu_inverse_bytes(bytea) RETURNS bytea +TRANSFORM FOR TYPE bytea +AS $$ + return join '', reverse split('', $_[0]); +$$ LANGUAGE plperlu; + +SELECT 'ξενία'::bytea, perlu_inverse_bytes('ξενία'::bytea); + +DROP EXTENSION plperlu CASCADE; diff --git a/contrib/meson.build b/contrib/meson.build index c12dc906ca..7fe53fafeb 100644 --- a/contrib/meson.build +++ b/contrib/meson.build @@ -22,6 +22,7 @@ subdir('basebackup_to_shell') subdir('bool_plperl') subdir('btree_gin') subdir('btree_gist') +subdir('bytea_plperl') subdir('citext') subdir('cube') subdir('dblink') diff --git a/doc/src/sgml/plperl.sgml b/doc/src/sgml/plperl.sgml index 25b1077ad7..eea293eaec 100644 --- a/doc/src/sgml/plperl.sgml +++ b/doc/src/sgml/plperl.sgml @@ -224,6 +224,22 @@ $$ LANGUAGE plperl; (<xref linkend="plperl-database"/>). </para> + <para> + Normally the <type>bytea</type> arguments are seen by Perl as strings in hex format (see + <xref linkend="datatype-binary"/>). + If the transform defined by the <filename>bytea_plperl</filename> extension is used, they are + passed and returned as native Perl octet strings, see example below: +<programlisting> +CREATE EXTENSION bytea_plperl; -- or bool_plperlu for PL/PerlU +CREATE FUNCTION perl_inverse_bytes(bytea) RETURNS bytea +TRANSFORM FOR TYPE bytea +AS $$ + return join '', reverse split('', $_[0]); +$$ LANGUAGE plperl; +</programlisting> + + </para> + <para> Perl can return <productname>PostgreSQL</productname> arrays as references to Perl arrays. Here is an example: -- 2.43.0 ^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Bytea PL/Perl transform @ 2024-01-30 15:43 Dagfinn Ilmari Mannsåker <[email protected]> parent: Pavel Stehule <[email protected]> 0 siblings, 1 reply; 15+ messages in thread From: Dagfinn Ilmari Mannsåker @ 2024-01-30 15:43 UTC (permalink / raw) To: Pavel Stehule <[email protected]>; +Cc: vignesh C <[email protected]>; Ivan Panchenko <[email protected]>; Tom Lane <[email protected]>; Peter Eisentraut <[email protected]>; [email protected]; Greg Sabino Mullane <[email protected]> Pavel Stehule <[email protected]> writes: > I inserted perl reference support - hstore_plperl and json_plperl does it. > > +<->/* Dereference references recursively. */ > +<->while (SvROK(in)) > +<-><-->in = SvRV(in); That code in hstore_plperl and json_plperl is only relevant because they deal with non-scalar values (hashes for hstore, and also arrays for json) which must be passed as references. The recursive nature of the dereferencing is questionable, and masked the bug fixed by commit 1731e3741cbbf8e0b4481665d7d523bc55117f63. bytea_plperl only deals with scalars (specifically strings), so should not concern itself with references. In fact, this code breaks returning objects with overloaded stringification, for example: CREATE FUNCTION plperlu_overload() RETURNS bytea LANGUAGE plperlu TRANSFORM FOR TYPE bytea AS $$ package StringOverload { use overload '""' => sub { "stuff" }; } return bless {}, "StringOverload"; $$; This makes the server crash with an assertion failure from Perl because SvPVbyte() was passed a non-scalar value: postgres: ilmari regression_bytea_plperl [local] SELECT: sv.c:2865: Perl_sv_2pv_flags: Assertion `SvTYPE(sv) != SVt_PVAV && SvTYPE(sv) != SVt_PVHV && SvTYPE(sv) != SVt_PVFM' failed. If I remove the dereferincing loop it succeeds: SELECT encode(plperlu_overload(), 'escape') AS string; string -------- stuff (1 row) Attached is a v2 patch which removes the dereferencing and includes the above example as a test. - ilmari ^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Bytea PL/Perl transform @ 2024-01-30 16:05 Pavel Stehule <[email protected]> parent: Dagfinn Ilmari Mannsåker <[email protected]> 0 siblings, 1 reply; 15+ messages in thread From: Pavel Stehule @ 2024-01-30 16:05 UTC (permalink / raw) To: Dagfinn Ilmari Mannsåker <[email protected]>; +Cc: vignesh C <[email protected]>; Ivan Panchenko <[email protected]>; Tom Lane <[email protected]>; Peter Eisentraut <[email protected]>; [email protected]; Greg Sabino Mullane <[email protected]> út 30. 1. 2024 v 16:43 odesílatel Dagfinn Ilmari Mannsåker < [email protected]> napsal: > Pavel Stehule <[email protected]> writes: > > > I inserted perl reference support - hstore_plperl and json_plperl does > it. > > > > +<->/* Dereference references recursively. */ > > +<->while (SvROK(in)) > > +<-><-->in = SvRV(in); > > That code in hstore_plperl and json_plperl is only relevant because they > deal with non-scalar values (hashes for hstore, and also arrays for > json) which must be passed as references. The recursive nature of the > dereferencing is questionable, and masked the bug fixed by commit > 1731e3741cbbf8e0b4481665d7d523bc55117f63. > > bytea_plperl only deals with scalars (specifically strings), so should > not concern itself with references. In fact, this code breaks returning > objects with overloaded stringification, for example: > > CREATE FUNCTION plperlu_overload() RETURNS bytea LANGUAGE plperlu > TRANSFORM FOR TYPE bytea > AS $$ > package StringOverload { use overload '""' => sub { "stuff" }; } > return bless {}, "StringOverload"; > $$; > > This makes the server crash with an assertion failure from Perl because > SvPVbyte() was passed a non-scalar value: > > postgres: ilmari regression_bytea_plperl [local] SELECT: sv.c:2865: > Perl_sv_2pv_flags: > Assertion `SvTYPE(sv) != SVt_PVAV && SvTYPE(sv) != SVt_PVHV && SvTYPE(sv) > != SVt_PVFM' failed. > > If I remove the dereferincing loop it succeeds: > > SELECT encode(plperlu_overload(), 'escape') AS string; > string > -------- > stuff > (1 row) > > Attached is a v2 patch which removes the dereferencing and includes the > above example as a test. > But without dereference it returns bad value. Maybe there should be a check so references cannot be returned? Probably is not safe pass pointers between Perl and Postgres. > > - ilmari > > ^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Bytea PL/Perl transform @ 2024-01-30 16:18 Dagfinn Ilmari Mannsåker <[email protected]> parent: Pavel Stehule <[email protected]> 0 siblings, 1 reply; 15+ messages in thread From: Dagfinn Ilmari Mannsåker @ 2024-01-30 16:18 UTC (permalink / raw) To: Pavel Stehule <[email protected]>; +Cc: vignesh C <[email protected]>; Ivan Panchenko <[email protected]>; Tom Lane <[email protected]>; Peter Eisentraut <[email protected]>; [email protected]; Greg Sabino Mullane <[email protected]> Pavel Stehule <[email protected]> writes: > út 30. 1. 2024 v 16:43 odesílatel Dagfinn Ilmari Mannsåker < > [email protected]> napsal: > >> Pavel Stehule <[email protected]> writes: >> >> > I inserted perl reference support - hstore_plperl and json_plperl does >> it. >> > >> > +<->/* Dereference references recursively. */ >> > +<->while (SvROK(in)) >> > +<-><-->in = SvRV(in); >> >> That code in hstore_plperl and json_plperl is only relevant because they >> deal with non-scalar values (hashes for hstore, and also arrays for >> json) which must be passed as references. The recursive nature of the >> dereferencing is questionable, and masked the bug fixed by commit >> 1731e3741cbbf8e0b4481665d7d523bc55117f63. >> >> bytea_plperl only deals with scalars (specifically strings), so should >> not concern itself with references. In fact, this code breaks returning >> objects with overloaded stringification, for example: >> >> CREATE FUNCTION plperlu_overload() RETURNS bytea LANGUAGE plperlu >> TRANSFORM FOR TYPE bytea >> AS $$ >> package StringOverload { use overload '""' => sub { "stuff" }; } >> return bless {}, "StringOverload"; >> $$; >> >> This makes the server crash with an assertion failure from Perl because >> SvPVbyte() was passed a non-scalar value: >> >> postgres: ilmari regression_bytea_plperl [local] SELECT: sv.c:2865: >> Perl_sv_2pv_flags: >> Assertion `SvTYPE(sv) != SVt_PVAV && SvTYPE(sv) != SVt_PVHV && SvTYPE(sv) >> != SVt_PVFM' failed. >> >> If I remove the dereferincing loop it succeeds: >> >> SELECT encode(plperlu_overload(), 'escape') AS string; >> string >> -------- >> stuff >> (1 row) >> >> Attached is a v2 patch which removes the dereferencing and includes the >> above example as a test. >> > > But without dereference it returns bad value. Where exactly does it return a bad value? The existing tests pass, and the one I included shows that it does the right thing in that case too. If you pass it an unblessed reference it returns the stringified version of that, as expected. CREATE FUNCTION plperl_reference() RETURNS bytea LANGUAGE plperl TRANSFORM FOR TYPE bytea AS $$ return []; $$; SELECT encode(plperl_reference(), 'escape') string; string ----------------------- ARRAY(0x559a3109f0a8) (1 row) This would also crash if the dereferencing loop was left in place. > Maybe there should be a check so references cannot be returned? Probably is > not safe pass pointers between Perl and Postgres. There's no reason to ban references, that would break every Perl programmer's expectations. And there are no pointers being passed, SvPVbyte() returns the stringified form of whatever's passed in, which is well-behaved for both blessed and unblessed references. If we really want to be strict, we should at least allow references to objects that overload stringification, as they are explicitly designed to be well-behaved as strings. But that would be a lot of extra code for very little benefit over just letting Perl stringify everything. - ilmari ^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Bytea PL/Perl transform @ 2024-01-30 16:24 Pavel Stehule <[email protected]> parent: Dagfinn Ilmari Mannsåker <[email protected]> 0 siblings, 1 reply; 15+ messages in thread From: Pavel Stehule @ 2024-01-30 16:24 UTC (permalink / raw) To: Dagfinn Ilmari Mannsåker <[email protected]>; +Cc: vignesh C <[email protected]>; Ivan Panchenko <[email protected]>; Tom Lane <[email protected]>; Peter Eisentraut <[email protected]>; [email protected]; Greg Sabino Mullane <[email protected]> út 30. 1. 2024 v 17:18 odesílatel Dagfinn Ilmari Mannsåker < [email protected]> napsal: > Pavel Stehule <[email protected]> writes: > > > út 30. 1. 2024 v 16:43 odesílatel Dagfinn Ilmari Mannsåker < > > [email protected]> napsal: > > > >> Pavel Stehule <[email protected]> writes: > >> > >> > I inserted perl reference support - hstore_plperl and json_plperl does > >> it. > >> > > >> > +<->/* Dereference references recursively. */ > >> > +<->while (SvROK(in)) > >> > +<-><-->in = SvRV(in); > >> > >> That code in hstore_plperl and json_plperl is only relevant because they > >> deal with non-scalar values (hashes for hstore, and also arrays for > >> json) which must be passed as references. The recursive nature of the > >> dereferencing is questionable, and masked the bug fixed by commit > >> 1731e3741cbbf8e0b4481665d7d523bc55117f63. > >> > >> bytea_plperl only deals with scalars (specifically strings), so should > >> not concern itself with references. In fact, this code breaks returning > >> objects with overloaded stringification, for example: > >> > >> CREATE FUNCTION plperlu_overload() RETURNS bytea LANGUAGE plperlu > >> TRANSFORM FOR TYPE bytea > >> AS $$ > >> package StringOverload { use overload '""' => sub { "stuff" }; } > >> return bless {}, "StringOverload"; > >> $$; > >> > >> This makes the server crash with an assertion failure from Perl because > >> SvPVbyte() was passed a non-scalar value: > >> > >> postgres: ilmari regression_bytea_plperl [local] SELECT: sv.c:2865: > >> Perl_sv_2pv_flags: > >> Assertion `SvTYPE(sv) != SVt_PVAV && SvTYPE(sv) != SVt_PVHV && > SvTYPE(sv) > >> != SVt_PVFM' failed. > >> > >> If I remove the dereferincing loop it succeeds: > >> > >> SELECT encode(plperlu_overload(), 'escape') AS string; > >> string > >> -------- > >> stuff > >> (1 row) > >> > >> Attached is a v2 patch which removes the dereferencing and includes the > >> above example as a test. > >> > > > > But without dereference it returns bad value. > > Where exactly does it return a bad value? The existing tests pass, and > the one I included shows that it does the right thing in that case too. > If you pass it an unblessed reference it returns the stringified version > of that, as expected. > ugly test code (2024-01-30 13:44:28) postgres=# CREATE or replace FUNCTION perl_inverse_bytes(bytea) RETURNS bytea TRANSFORM FOR TYPE bytea AS $$ my $bytes = pack 'H*', '0123'; my $ref = \$bytes; return $ref; $$ LANGUAGE plperlu; CREATE FUNCTION (2024-01-30 13:44:33) postgres=# select perl_inverse_bytes(''), ' '::bytea; ┌──────────────────────────────────────┬───────┐ │ perl_inverse_bytes │ bytea │ ╞══════════════════════════════════════╪═══════╡ │ \x5343414c41522830783130656134333829 │ \x20 │ └──────────────────────────────────────┴───────┘ (1 row) expected (2024-01-30 13:46:58) postgres=# select perl_inverse_bytes(''), ' '::bytea; ┌────────────────────┬───────┐ │ perl_inverse_bytes │ bytea │ ╞════════════════════╪═══════╡ │ \x0123 │ \x20 │ └────────────────────┴───────┘ (1 row) > > CREATE FUNCTION plperl_reference() RETURNS bytea LANGUAGE plperl > TRANSFORM FOR TYPE bytea > AS $$ return []; $$; > > SELECT encode(plperl_reference(), 'escape') string; > string > ----------------------- > ARRAY(0x559a3109f0a8) > (1 row) > > This would also crash if the dereferencing loop was left in place. > > > Maybe there should be a check so references cannot be returned? Probably > is > > not safe pass pointers between Perl and Postgres. > > There's no reason to ban references, that would break every Perl > programmer's expectations. And there are no pointers being passed, > SvPVbyte() returns the stringified form of whatever's passed in, which > is well-behaved for both blessed and unblessed references. > > If we really want to be strict, we should at least allow references to > objects that overload stringification, as they are explicitly designed > to be well-behaved as strings. But that would be a lot of extra code > for very little benefit over just letting Perl stringify everything. > > - ilmari > ^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Bytea PL/Perl transform @ 2024-01-30 16:46 Dagfinn Ilmari Mannsåker <[email protected]> parent: Pavel Stehule <[email protected]> 0 siblings, 1 reply; 15+ messages in thread From: Dagfinn Ilmari Mannsåker @ 2024-01-30 16:46 UTC (permalink / raw) To: Pavel Stehule <[email protected]>; +Cc: vignesh C <[email protected]>; Ivan Panchenko <[email protected]>; Tom Lane <[email protected]>; Peter Eisentraut <[email protected]>; [email protected]; Greg Sabino Mullane <[email protected]> Pavel Stehule <[email protected]> writes: > út 30. 1. 2024 v 17:18 odesílatel Dagfinn Ilmari Mannsåker < > [email protected]> napsal: > >> Pavel Stehule <[email protected]> writes: >> >> > út 30. 1. 2024 v 16:43 odesílatel Dagfinn Ilmari Mannsåker < >> > [email protected]> napsal: >> > >> >> Pavel Stehule <[email protected]> writes: >> >> >> >> > I inserted perl reference support - hstore_plperl and json_plperl does >> >> it. >> >> > >> >> > +<->/* Dereference references recursively. */ >> >> > +<->while (SvROK(in)) >> >> > +<-><-->in = SvRV(in); >> >> >> >> That code in hstore_plperl and json_plperl is only relevant because they >> >> deal with non-scalar values (hashes for hstore, and also arrays for >> >> json) which must be passed as references. The recursive nature of the >> >> dereferencing is questionable, and masked the bug fixed by commit >> >> 1731e3741cbbf8e0b4481665d7d523bc55117f63. >> >> >> >> bytea_plperl only deals with scalars (specifically strings), so should >> >> not concern itself with references. In fact, this code breaks returning >> >> objects with overloaded stringification, for example: >> >> >> >> CREATE FUNCTION plperlu_overload() RETURNS bytea LANGUAGE plperlu >> >> TRANSFORM FOR TYPE bytea >> >> AS $$ >> >> package StringOverload { use overload '""' => sub { "stuff" }; } >> >> return bless {}, "StringOverload"; >> >> $$; >> >> >> >> This makes the server crash with an assertion failure from Perl because >> >> SvPVbyte() was passed a non-scalar value: >> >> >> >> postgres: ilmari regression_bytea_plperl [local] SELECT: sv.c:2865: >> >> Perl_sv_2pv_flags: >> >> Assertion `SvTYPE(sv) != SVt_PVAV && SvTYPE(sv) != SVt_PVHV && >> SvTYPE(sv) >> >> != SVt_PVFM' failed. >> >> >> >> If I remove the dereferincing loop it succeeds: >> >> >> >> SELECT encode(plperlu_overload(), 'escape') AS string; >> >> string >> >> -------- >> >> stuff >> >> (1 row) >> >> >> >> Attached is a v2 patch which removes the dereferencing and includes the >> >> above example as a test. >> >> >> > >> > But without dereference it returns bad value. >> >> Where exactly does it return a bad value? The existing tests pass, and >> the one I included shows that it does the right thing in that case too. >> If you pass it an unblessed reference it returns the stringified version >> of that, as expected. >> > > ugly test code > > (2024-01-30 13:44:28) postgres=# CREATE or replace FUNCTION > perl_inverse_bytes(bytea) RETURNS bytea > TRANSFORM FOR TYPE bytea > AS $$ my $bytes = pack 'H*', '0123'; my $ref = \$bytes; You are returning a reference, not a string. > return $ref; > $$ LANGUAGE plperlu; > CREATE FUNCTION > (2024-01-30 13:44:33) postgres=# select perl_inverse_bytes(''), ' '::bytea; > ┌──────────────────────────────────────┬───────┐ > │ perl_inverse_bytes │ bytea │ > ╞══════════════════════════════════════╪═══════╡ > │ \x5343414c41522830783130656134333829 │ \x20 │ > └──────────────────────────────────────┴───────┘ > (1 row) ~=# select encode('\x5343414c41522830783130656134333829', 'escape'); ┌───────────────────┐ │ encode │ ├───────────────────┤ │ SCALAR(0x10ea438) │ └───────────────────┘ This is how Perl stringifies references in the absence of overloading. Return the byte string directly from your function and it will do the right thing: CREATE FUNCTION plperlu_bytes() RETURNS bytea LANGUAGE plperlu TRANSFORM FOR TYPE bytea AS $$ return pack 'H*', '0123'; $$; SELECT plperlu_bytes(); plperlu_bytes --------------- \x0123 (1 row) - ilmari ^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Bytea PL/Perl transform @ 2024-01-30 16:49 Pavel Stehule <[email protected]> parent: Dagfinn Ilmari Mannsåker <[email protected]> 0 siblings, 1 reply; 15+ messages in thread From: Pavel Stehule @ 2024-01-30 16:49 UTC (permalink / raw) To: Dagfinn Ilmari Mannsåker <[email protected]>; +Cc: vignesh C <[email protected]>; Ivan Panchenko <[email protected]>; Tom Lane <[email protected]>; Peter Eisentraut <[email protected]>; [email protected]; Greg Sabino Mullane <[email protected]> út 30. 1. 2024 v 17:46 odesílatel Dagfinn Ilmari Mannsåker < [email protected]> napsal: > Pavel Stehule <[email protected]> writes: > > > út 30. 1. 2024 v 17:18 odesílatel Dagfinn Ilmari Mannsåker < > > [email protected]> napsal: > > > >> Pavel Stehule <[email protected]> writes: > >> > >> > út 30. 1. 2024 v 16:43 odesílatel Dagfinn Ilmari Mannsåker < > >> > [email protected]> napsal: > >> > > >> >> Pavel Stehule <[email protected]> writes: > >> >> > >> >> > I inserted perl reference support - hstore_plperl and json_plperl > does > >> >> it. > >> >> > > >> >> > +<->/* Dereference references recursively. */ > >> >> > +<->while (SvROK(in)) > >> >> > +<-><-->in = SvRV(in); > >> >> > >> >> That code in hstore_plperl and json_plperl is only relevant because > they > >> >> deal with non-scalar values (hashes for hstore, and also arrays for > >> >> json) which must be passed as references. The recursive nature of > the > >> >> dereferencing is questionable, and masked the bug fixed by commit > >> >> 1731e3741cbbf8e0b4481665d7d523bc55117f63. > >> >> > >> >> bytea_plperl only deals with scalars (specifically strings), so > should > >> >> not concern itself with references. In fact, this code breaks > returning > >> >> objects with overloaded stringification, for example: > >> >> > >> >> CREATE FUNCTION plperlu_overload() RETURNS bytea LANGUAGE plperlu > >> >> TRANSFORM FOR TYPE bytea > >> >> AS $$ > >> >> package StringOverload { use overload '""' => sub { "stuff" }; } > >> >> return bless {}, "StringOverload"; > >> >> $$; > >> >> > >> >> This makes the server crash with an assertion failure from Perl > because > >> >> SvPVbyte() was passed a non-scalar value: > >> >> > >> >> postgres: ilmari regression_bytea_plperl [local] SELECT: sv.c:2865: > >> >> Perl_sv_2pv_flags: > >> >> Assertion `SvTYPE(sv) != SVt_PVAV && SvTYPE(sv) != SVt_PVHV && > >> SvTYPE(sv) > >> >> != SVt_PVFM' failed. > >> >> > >> >> If I remove the dereferincing loop it succeeds: > >> >> > >> >> SELECT encode(plperlu_overload(), 'escape') AS string; > >> >> string > >> >> -------- > >> >> stuff > >> >> (1 row) > >> >> > >> >> Attached is a v2 patch which removes the dereferencing and includes > the > >> >> above example as a test. > >> >> > >> > > >> > But without dereference it returns bad value. > >> > >> Where exactly does it return a bad value? The existing tests pass, and > >> the one I included shows that it does the right thing in that case too. > >> If you pass it an unblessed reference it returns the stringified version > >> of that, as expected. > >> > > > > ugly test code > > > > (2024-01-30 13:44:28) postgres=# CREATE or replace FUNCTION > > perl_inverse_bytes(bytea) RETURNS bytea > > TRANSFORM FOR TYPE bytea > > AS $$ my $bytes = pack 'H*', '0123'; my $ref = \$bytes; > > You are returning a reference, not a string. > I know, but for this case, should not be raised an error? > > > return $ref; > > $$ LANGUAGE plperlu; > > CREATE FUNCTION > > (2024-01-30 13:44:33) postgres=# select perl_inverse_bytes(''), ' > '::bytea; > > ┌──────────────────────────────────────┬───────┐ > > │ perl_inverse_bytes │ bytea │ > > ╞══════════════════════════════════════╪═══════╡ > > │ \x5343414c41522830783130656134333829 │ \x20 │ > > └──────────────────────────────────────┴───────┘ > > (1 row) > > ~=# select encode('\x5343414c41522830783130656134333829', 'escape'); > ┌───────────────────┐ > │ encode │ > ├───────────────────┤ > │ SCALAR(0x10ea438) │ > └───────────────────┘ > > This is how Perl stringifies references in the absence of overloading. > Return the byte string directly from your function and it will do the > right thing: > > CREATE FUNCTION plperlu_bytes() RETURNS bytea LANGUAGE plperlu > TRANSFORM FOR TYPE bytea > AS $$ return pack 'H*', '0123'; $$; > > SELECT plperlu_bytes(); > plperlu_bytes > --------------- > \x0123 > (1 row) > > > - ilmari > ^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Bytea PL/Perl transform @ 2024-01-30 17:26 Dagfinn Ilmari Mannsåker <[email protected]> parent: Pavel Stehule <[email protected]> 0 siblings, 1 reply; 15+ messages in thread From: Dagfinn Ilmari Mannsåker @ 2024-01-30 17:26 UTC (permalink / raw) To: Pavel Stehule <[email protected]>; +Cc: vignesh C <[email protected]>; Ivan Panchenko <[email protected]>; Tom Lane <[email protected]>; Peter Eisentraut <[email protected]>; [email protected]; Greg Sabino Mullane <[email protected]> Pavel Stehule <[email protected]> writes: > út 30. 1. 2024 v 17:46 odesílatel Dagfinn Ilmari Mannsåker < > [email protected]> napsal: > >> Pavel Stehule <[email protected]> writes: >> >> > út 30. 1. 2024 v 17:18 odesílatel Dagfinn Ilmari Mannsåker < >> > [email protected]> napsal: >> > >> >> Pavel Stehule <[email protected]> writes: >> >> >> >> > út 30. 1. 2024 v 16:43 odesílatel Dagfinn Ilmari Mannsåker < >> >> > [email protected]> napsal: >> >> > >> >> >> Pavel Stehule <[email protected]> writes: >> >> >> >> >> >> > I inserted perl reference support - hstore_plperl and json_plperl >> does >> >> >> it. >> >> >> > >> >> >> > +<->/* Dereference references recursively. */ >> >> >> > +<->while (SvROK(in)) >> >> >> > +<-><-->in = SvRV(in); >> >> >> >> >> >> That code in hstore_plperl and json_plperl is only relevant because >> they >> >> >> deal with non-scalar values (hashes for hstore, and also arrays for >> >> >> json) which must be passed as references. The recursive nature of >> the >> >> >> dereferencing is questionable, and masked the bug fixed by commit >> >> >> 1731e3741cbbf8e0b4481665d7d523bc55117f63. >> >> >> >> >> >> bytea_plperl only deals with scalars (specifically strings), so >> should >> >> >> not concern itself with references. In fact, this code breaks >> returning >> >> >> objects with overloaded stringification, for example: >> >> >> >> >> >> CREATE FUNCTION plperlu_overload() RETURNS bytea LANGUAGE plperlu >> >> >> TRANSFORM FOR TYPE bytea >> >> >> AS $$ >> >> >> package StringOverload { use overload '""' => sub { "stuff" }; } >> >> >> return bless {}, "StringOverload"; >> >> >> $$; >> >> >> >> >> >> This makes the server crash with an assertion failure from Perl >> because >> >> >> SvPVbyte() was passed a non-scalar value: >> >> >> >> >> >> postgres: ilmari regression_bytea_plperl [local] SELECT: sv.c:2865: >> >> >> Perl_sv_2pv_flags: >> >> >> Assertion `SvTYPE(sv) != SVt_PVAV && SvTYPE(sv) != SVt_PVHV && >> >> SvTYPE(sv) >> >> >> != SVt_PVFM' failed. >> >> >> >> >> >> If I remove the dereferincing loop it succeeds: >> >> >> >> >> >> SELECT encode(plperlu_overload(), 'escape') AS string; >> >> >> string >> >> >> -------- >> >> >> stuff >> >> >> (1 row) >> >> >> >> >> >> Attached is a v2 patch which removes the dereferencing and includes >> the >> >> >> above example as a test. >> >> >> >> >> > >> >> > But without dereference it returns bad value. >> >> >> >> Where exactly does it return a bad value? The existing tests pass, and >> >> the one I included shows that it does the right thing in that case too. >> >> If you pass it an unblessed reference it returns the stringified version >> >> of that, as expected. >> >> >> > >> > ugly test code >> > >> > (2024-01-30 13:44:28) postgres=# CREATE or replace FUNCTION >> > perl_inverse_bytes(bytea) RETURNS bytea >> > TRANSFORM FOR TYPE bytea >> > AS $$ my $bytes = pack 'H*', '0123'; my $ref = \$bytes; >> >> You are returning a reference, not a string. >> > > I know, but for this case, should not be raised an error? I don't think so, as I explained in my previous reply: > There's no reason to ban references, that would break every Perl > programmer's expectations. To elaborate on this: when a function is defined to return a string (which bytea effectively is, as far as Perl is converned), I as a Perl programmer would expect PL/Perl to just stringify whatever value I returned, according to the usual Perl rules. I also said: > If we really want to be strict, we should at least allow references to > objects that overload stringification, as they are explicitly designed > to be well-behaved as strings. But that would be a lot of extra code > for very little benefit over just letting Perl stringify everything. By "a lot of code", I mean everything `string_amg`-related in the amagic_applies() function (https://github.com/Perl/perl5/blob/v5.38.0/gv.c#L3401-L3545). We can't just call it: it's only available since Perl 5.38 (released last year), and we support Perl versions all the way back to 5.14. - ilmari ^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Bytea PL/Perl transform @ 2024-01-30 17:35 Pavel Stehule <[email protected]> parent: Dagfinn Ilmari Mannsåker <[email protected]> 0 siblings, 1 reply; 15+ messages in thread From: Pavel Stehule @ 2024-01-30 17:35 UTC (permalink / raw) To: Dagfinn Ilmari Mannsåker <[email protected]>; +Cc: vignesh C <[email protected]>; Ivan Panchenko <[email protected]>; Tom Lane <[email protected]>; Peter Eisentraut <[email protected]>; [email protected]; Greg Sabino Mullane <[email protected]> út 30. 1. 2024 v 18:26 odesílatel Dagfinn Ilmari Mannsåker < [email protected]> napsal: > Pavel Stehule <[email protected]> writes: > > > út 30. 1. 2024 v 17:46 odesílatel Dagfinn Ilmari Mannsåker < > > [email protected]> napsal: > > > >> Pavel Stehule <[email protected]> writes: > >> > >> > út 30. 1. 2024 v 17:18 odesílatel Dagfinn Ilmari Mannsåker < > >> > [email protected]> napsal: > >> > > >> >> Pavel Stehule <[email protected]> writes: > >> >> > >> >> > út 30. 1. 2024 v 16:43 odesílatel Dagfinn Ilmari Mannsåker < > >> >> > [email protected]> napsal: > >> >> > > >> >> >> Pavel Stehule <[email protected]> writes: > >> >> >> > >> >> >> > I inserted perl reference support - hstore_plperl and > json_plperl > >> does > >> >> >> it. > >> >> >> > > >> >> >> > +<->/* Dereference references recursively. */ > >> >> >> > +<->while (SvROK(in)) > >> >> >> > +<-><-->in = SvRV(in); > >> >> >> > >> >> >> That code in hstore_plperl and json_plperl is only relevant > because > >> they > >> >> >> deal with non-scalar values (hashes for hstore, and also arrays > for > >> >> >> json) which must be passed as references. The recursive nature of > >> the > >> >> >> dereferencing is questionable, and masked the bug fixed by commit > >> >> >> 1731e3741cbbf8e0b4481665d7d523bc55117f63. > >> >> >> > >> >> >> bytea_plperl only deals with scalars (specifically strings), so > >> should > >> >> >> not concern itself with references. In fact, this code breaks > >> returning > >> >> >> objects with overloaded stringification, for example: > >> >> >> > >> >> >> CREATE FUNCTION plperlu_overload() RETURNS bytea LANGUAGE plperlu > >> >> >> TRANSFORM FOR TYPE bytea > >> >> >> AS $$ > >> >> >> package StringOverload { use overload '""' => sub { "stuff" > }; } > >> >> >> return bless {}, "StringOverload"; > >> >> >> $$; > >> >> >> > >> >> >> This makes the server crash with an assertion failure from Perl > >> because > >> >> >> SvPVbyte() was passed a non-scalar value: > >> >> >> > >> >> >> postgres: ilmari regression_bytea_plperl [local] SELECT: > sv.c:2865: > >> >> >> Perl_sv_2pv_flags: > >> >> >> Assertion `SvTYPE(sv) != SVt_PVAV && SvTYPE(sv) != SVt_PVHV && > >> >> SvTYPE(sv) > >> >> >> != SVt_PVFM' failed. > >> >> >> > >> >> >> If I remove the dereferincing loop it succeeds: > >> >> >> > >> >> >> SELECT encode(plperlu_overload(), 'escape') AS string; > >> >> >> string > >> >> >> -------- > >> >> >> stuff > >> >> >> (1 row) > >> >> >> > >> >> >> Attached is a v2 patch which removes the dereferencing and > includes > >> the > >> >> >> above example as a test. > >> >> >> > >> >> > > >> >> > But without dereference it returns bad value. > >> >> > >> >> Where exactly does it return a bad value? The existing tests pass, > and > >> >> the one I included shows that it does the right thing in that case > too. > >> >> If you pass it an unblessed reference it returns the stringified > version > >> >> of that, as expected. > >> >> > >> > > >> > ugly test code > >> > > >> > (2024-01-30 13:44:28) postgres=# CREATE or replace FUNCTION > >> > perl_inverse_bytes(bytea) RETURNS bytea > >> > TRANSFORM FOR TYPE bytea > >> > AS $$ my $bytes = pack 'H*', '0123'; my $ref = \$bytes; > >> > >> You are returning a reference, not a string. > >> > > > > I know, but for this case, should not be raised an error? > > I don't think so, as I explained in my previous reply: > > > There's no reason to ban references, that would break every Perl > > programmer's expectations. > > To elaborate on this: when a function is defined to return a string > (which bytea effectively is, as far as Perl is converned), I as a Perl > programmer would expect PL/Perl to just stringify whatever value I > returned, according to the usual Perl rules. > ok Pavel > > I also said: > > > If we really want to be strict, we should at least allow references to > > objects that overload stringification, as they are explicitly designed > > to be well-behaved as strings. But that would be a lot of extra code > > for very little benefit over just letting Perl stringify everything. > > By "a lot of code", I mean everything `string_amg`-related in the > amagic_applies() function > (https://github.com/Perl/perl5/blob/v5.38.0/gv.c#L3401-L3545). We can't > just call it: it's only available since Perl 5.38 (released last year), > and we support Perl versions all the way back to 5.14. > > - ilmari > ^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Bytea PL/Perl transform @ 2024-01-30 18:45 Pavel Stehule <[email protected]> parent: Pavel Stehule <[email protected]> 0 siblings, 1 reply; 15+ messages in thread From: Pavel Stehule @ 2024-01-30 18:45 UTC (permalink / raw) To: Dagfinn Ilmari Mannsåker <[email protected]>; +Cc: vignesh C <[email protected]>; Ivan Panchenko <[email protected]>; Tom Lane <[email protected]>; Peter Eisentraut <[email protected]>; [email protected]; Greg Sabino Mullane <[email protected]> Hi út 30. 1. 2024 v 18:35 odesílatel Pavel Stehule <[email protected]> napsal: > > > út 30. 1. 2024 v 18:26 odesílatel Dagfinn Ilmari Mannsåker < > [email protected]> napsal: > >> Pavel Stehule <[email protected]> writes: >> >> > út 30. 1. 2024 v 17:46 odesílatel Dagfinn Ilmari Mannsåker < >> > [email protected]> napsal: >> > >> >> Pavel Stehule <[email protected]> writes: >> >> >> >> > út 30. 1. 2024 v 17:18 odesílatel Dagfinn Ilmari Mannsåker < >> >> > [email protected]> napsal: >> >> > >> >> >> Pavel Stehule <[email protected]> writes: >> >> >> >> >> >> > út 30. 1. 2024 v 16:43 odesílatel Dagfinn Ilmari Mannsåker < >> >> >> > [email protected]> napsal: >> >> >> > >> >> >> >> Pavel Stehule <[email protected]> writes: >> >> >> >> >> >> >> >> > I inserted perl reference support - hstore_plperl and >> json_plperl >> >> does >> >> >> >> it. >> >> >> >> > >> >> >> >> > +<->/* Dereference references recursively. */ >> >> >> >> > +<->while (SvROK(in)) >> >> >> >> > +<-><-->in = SvRV(in); >> >> >> >> >> >> >> >> That code in hstore_plperl and json_plperl is only relevant >> because >> >> they >> >> >> >> deal with non-scalar values (hashes for hstore, and also arrays >> for >> >> >> >> json) which must be passed as references. The recursive nature >> of >> >> the >> >> >> >> dereferencing is questionable, and masked the bug fixed by commit >> >> >> >> 1731e3741cbbf8e0b4481665d7d523bc55117f63. >> >> >> >> >> >> >> >> bytea_plperl only deals with scalars (specifically strings), so >> >> should >> >> >> >> not concern itself with references. In fact, this code breaks >> >> returning >> >> >> >> objects with overloaded stringification, for example: >> >> >> >> >> >> >> >> CREATE FUNCTION plperlu_overload() RETURNS bytea LANGUAGE plperlu >> >> >> >> TRANSFORM FOR TYPE bytea >> >> >> >> AS $$ >> >> >> >> package StringOverload { use overload '""' => sub { "stuff" >> }; } >> >> >> >> return bless {}, "StringOverload"; >> >> >> >> $$; >> >> >> >> >> >> >> >> This makes the server crash with an assertion failure from Perl >> >> because >> >> >> >> SvPVbyte() was passed a non-scalar value: >> >> >> >> >> >> >> >> postgres: ilmari regression_bytea_plperl [local] SELECT: >> sv.c:2865: >> >> >> >> Perl_sv_2pv_flags: >> >> >> >> Assertion `SvTYPE(sv) != SVt_PVAV && SvTYPE(sv) != SVt_PVHV && >> >> >> SvTYPE(sv) >> >> >> >> != SVt_PVFM' failed. >> >> >> >> >> >> >> >> If I remove the dereferincing loop it succeeds: >> >> >> >> >> >> >> >> SELECT encode(plperlu_overload(), 'escape') AS string; >> >> >> >> string >> >> >> >> -------- >> >> >> >> stuff >> >> >> >> (1 row) >> >> >> >> >> >> >> >> Attached is a v2 patch which removes the dereferencing and >> includes >> >> the >> >> >> >> above example as a test. >> >> >> >> >> >> >> > >> >> >> > But without dereference it returns bad value. >> >> >> >> >> >> Where exactly does it return a bad value? The existing tests pass, >> and >> >> >> the one I included shows that it does the right thing in that case >> too. >> >> >> If you pass it an unblessed reference it returns the stringified >> version >> >> >> of that, as expected. >> >> >> >> >> > >> >> > ugly test code >> >> > >> >> > (2024-01-30 13:44:28) postgres=# CREATE or replace FUNCTION >> >> > perl_inverse_bytes(bytea) RETURNS bytea >> >> > TRANSFORM FOR TYPE bytea >> >> > AS $$ my $bytes = pack 'H*', '0123'; my $ref = \$bytes; >> >> >> >> You are returning a reference, not a string. >> >> >> > >> > I know, but for this case, should not be raised an error? >> >> I don't think so, as I explained in my previous reply: >> >> > There's no reason to ban references, that would break every Perl >> > programmer's expectations. >> >> To elaborate on this: when a function is defined to return a string >> (which bytea effectively is, as far as Perl is converned), I as a Perl >> programmer would expect PL/Perl to just stringify whatever value I >> returned, according to the usual Perl rules. >> > > ok > > Pavel > > >> >> I also said: >> >> > If we really want to be strict, we should at least allow references to >> > objects that overload stringification, as they are explicitly designed >> > to be well-behaved as strings. But that would be a lot of extra code >> > for very little benefit over just letting Perl stringify everything. >> > >> By "a lot of code", I mean everything `string_amg`-related in the >> amagic_applies() function >> (https://github.com/Perl/perl5/blob/v5.38.0/gv.c#L3401-L3545). We can't >> just call it: it's only available since Perl 5.38 (released last year), >> and we support Perl versions all the way back to 5.14. >> >> - ilmari >> > I marked this patch as ready for committer. It is almost trivial, make check-world, make doc passed Regards Pavel ^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Bytea PL/Perl transform @ 2024-02-27 20:03 Alexander Korotkov <[email protected]> parent: Pavel Stehule <[email protected]> 0 siblings, 2 replies; 15+ messages in thread From: Alexander Korotkov @ 2024-02-27 20:03 UTC (permalink / raw) To: Pavel Stehule <[email protected]>; +Cc: Dagfinn Ilmari Mannsåker <[email protected]>; vignesh C <[email protected]>; Ivan Panchenko <[email protected]>; Tom Lane <[email protected]>; Peter Eisentraut <[email protected]>; [email protected]; Greg Sabino Mullane <[email protected]> Hi! On Tue, Jan 30, 2024 at 8:46 PM Pavel Stehule <[email protected]> wrote: > I marked this patch as ready for committer. The last version of the patch still provides transform for builtin type in a separate extension. As discussed upthread such transforms don't need separate extensions, and could be provided as part of upgrades of existing extensions. There is probably no consensus yet on what to do with existing extensions like jsonb_plperl and jsonb_plpython, but we clearly shouldn't spread such cases. ------ Regards, Alexander Korotkov ^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Bytea PL/Perl transform @ 2024-02-28 04:02 Pavel Stehule <[email protected]> parent: Alexander Korotkov <[email protected]> 1 sibling, 0 replies; 15+ messages in thread From: Pavel Stehule @ 2024-02-28 04:02 UTC (permalink / raw) To: Alexander Korotkov <[email protected]>; +Cc: Dagfinn Ilmari Mannsåker <[email protected]>; vignesh C <[email protected]>; Ivan Panchenko <[email protected]>; Tom Lane <[email protected]>; Peter Eisentraut <[email protected]>; [email protected]; Greg Sabino Mullane <[email protected]> út 27. 2. 2024 v 21:03 odesílatel Alexander Korotkov <[email protected]> napsal: > Hi! > > On Tue, Jan 30, 2024 at 8:46 PM Pavel Stehule <[email protected]> > wrote: > > I marked this patch as ready for committer. > > The last version of the patch still provides transform for builtin > type in a separate extension. As discussed upthread such transforms > don't need separate extensions, and could be provided as part of > upgrades of existing extensions. There is probably no consensus yet > on what to do with existing extensions like jsonb_plperl and > jsonb_plpython, but we clearly shouldn't spread such cases. > +1 Pavel > ------ > Regards, > Alexander Korotkov > ^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Bytea PL/Perl transform @ 2024-03-21 21:30 Tom Lane <[email protected]> parent: Alexander Korotkov <[email protected]> 1 sibling, 0 replies; 15+ messages in thread From: Tom Lane @ 2024-03-21 21:30 UTC (permalink / raw) To: Alexander Korotkov <[email protected]>; +Cc: Pavel Stehule <[email protected]>; Dagfinn Ilmari Mannsåker <[email protected]>; vignesh C <[email protected]>; Ivan Panchenko <[email protected]>; Peter Eisentraut <[email protected]>; [email protected]; Greg Sabino Mullane <[email protected]> Alexander Korotkov <[email protected]> writes: > On Tue, Jan 30, 2024 at 8:46 PM Pavel Stehule <[email protected]> wrote: >> I marked this patch as ready for committer. > The last version of the patch still provides transform for builtin > type in a separate extension. As discussed upthread such transforms > don't need separate extensions, and could be provided as part of > upgrades of existing extensions. There is probably no consensus yet > on what to do with existing extensions like jsonb_plperl and > jsonb_plpython, but we clearly shouldn't spread such cases. Yeah, I think including this as part of "plperl[u] 1.1" is probably the best way forward. The patch of record doesn't do that, so I've set the CF entry back to Waiting On Author. Taking a quick look at the rest of the patch ... I think the documentation is pretty inadequate, as it just says that the transform causes byteas to be "passed and returned as native Perl octet strings", a term that it doesn't define, and googling doesn't exactly clarify either. The "example" is no example at all, as it does not show what happens or how the results are different. (Admittedly the nearby example for the bool transform is nearly as bad, but we could improve that too while we're at it.) regards, tom lane ^ permalink raw reply [nested|flat] 15+ messages in thread
end of thread, other threads:[~2024-03-21 21:30 UTC | newest] Thread overview: 15+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2020-09-12 13:07 [PATCH 9/9] Ignore correlation for new BRIN opclasses Tomas Vondra <[email protected]> 2024-01-06 15:51 Re: Bytea PL/Perl transform vignesh C <[email protected]> 2024-01-30 12:51 ` Re: Bytea PL/Perl transform Pavel Stehule <[email protected]> 2024-01-30 15:43 ` Re: Bytea PL/Perl transform Dagfinn Ilmari Mannsåker <[email protected]> 2024-01-30 16:05 ` Re: Bytea PL/Perl transform Pavel Stehule <[email protected]> 2024-01-30 16:18 ` Re: Bytea PL/Perl transform Dagfinn Ilmari Mannsåker <[email protected]> 2024-01-30 16:24 ` Re: Bytea PL/Perl transform Pavel Stehule <[email protected]> 2024-01-30 16:46 ` Re: Bytea PL/Perl transform Dagfinn Ilmari Mannsåker <[email protected]> 2024-01-30 16:49 ` Re: Bytea PL/Perl transform Pavel Stehule <[email protected]> 2024-01-30 17:26 ` Re: Bytea PL/Perl transform Dagfinn Ilmari Mannsåker <[email protected]> 2024-01-30 17:35 ` Re: Bytea PL/Perl transform Pavel Stehule <[email protected]> 2024-01-30 18:45 ` Re: Bytea PL/Perl transform Pavel Stehule <[email protected]> 2024-02-27 20:03 ` Re: Bytea PL/Perl transform Alexander Korotkov <[email protected]> 2024-02-28 04:02 ` Re: Bytea PL/Perl transform Pavel Stehule <[email protected]> 2024-03-21 21:30 ` Re: Bytea PL/Perl transform Tom Lane <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox