rdelaage
/
postgresql
mirror of https://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
postgresql/src/pl/plperl/plperl.c

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

4248 lines
111 KiB
C
Raw Normal View History

Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
/**********************************************************************
* plperl.c - perl as a procedural language for PostgreSQL
*
Remove cvs keywords from all files.
2010-09-20 22:08:53 +02:00
* src/pl/plperl/plperl.c
First round of changes for new fmgr interface. fmgr itself and the key call sites are changed, but most called functions are still oldstyle. An exception is that the PL managers are updated (so, for example, NULL handling now behaves as expected in plperl and plpgsql functions). NOTE initdb is forced due to added column in pg_proc.
2000-05-28 19:56:29 +02:00
*
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
**********************************************************************/
Fix plperl to discard cached function definition after CREATE OR REPLACE FUNCTION. Clean up typlen/typmod errors inherited from pltcl.
2001-10-20 00:43:49 +02:00
#include "postgres.h"
PL/Perl portability fix: avoid including XSUB.h in plperl.c. In Perl builds that define PERL_IMPLICIT_SYS, XSUB.h defines macros that replace a whole lot of basic libc functions with Perl functions. We can't tolerate that in plperl.c; it breaks at least PG_TRY and probably other stuff. The core idea of this patch is to include XSUB.h only in the .xs files where it's really needed, and to move any code broken by PERL_IMPLICIT_SYS out of the .xs files and into plperl.c. The reason this hasn't been a problem before is that our build techniques did not result in PERL_IMPLICIT_SYS appearing as a #define in PL/Perl, even on some platforms where Perl thinks it is defined. That's about to change in order to fix a nasty portability issue, so we need this work to make the code safe for that. Rather unaccountably, the Perl people chose XSUB.h as the place to provide the versions of the aTHX/aTHX_ macros that are needed by code that's not explicitly aware of the MULTIPLICITY API conventions. Hence, just removing XSUB.h from plperl.c fails miserably. But we can work around that by defining PERL_NO_GET_CONTEXT (which would make the relevant stanza of XSUB.h a no-op anyway). As explained in perlguts.pod, that means we need to add a "dTHX" macro call in every C function that calls a Perl API function. In most of them we just add this at the top; but since the macro fetches the current Perl interpreter pointer, more care is needed in functions that switch the active interpreter. Lack of the macro is easily recognized since it results in bleats about "my_perl" not being defined. (A nice side benefit of this is that it significantly reduces the number of fetches of the current interpreter pointer. On my machine, plperl.so gets more than 10% smaller, and there's probably some performance win too. We could reduce the number of fetches still more by decorating the code with pTHX_/aTHX_ macros to pass the interpreter pointer around, as explained by perlguts.pod; but that's a task for another day.) Formatting note: pgindent seems happy to treat "dTHX;" as a declaration so long as it's the first thing after the left brace, as we'd already observed with respect to the similar macro "dSP;". If you try to put it later in a set of declarations, pgindent puts ugly extra space around it. Having removed XSUB.h from plperl.c, we need only move the support functions for spi_return_next and util_elog (both of which use PG_TRY) out of the .xs files and into plperl.c. This seems sufficient to avoid the known problems caused by PERL_IMPLICIT_SYS, although we could move more code if additional issues emerge. This will need to be back-patched, but first let's see what the buildfarm makes of it. Patch by me, with some help from Ashutosh Sharma Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
2017-07-28 18:25:43 +02:00
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
/* system stuff */
Fix plperl's elog() function to convert elog(ERROR) into Perl croak(), rather than longjmp'ing clear out of Perl and thereby leaving Perl in a broken state. Also some minor prettification of error messages. Still need to do something with spi_exec_query() error handling.
2004-11-20 20:07:40 +01:00
#include <ctype.h>
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
#include <fcntl.h>
Widen query numbers-of-tuples-processed counters to uint64. This patch widens SPI_processed, EState's es_processed field, PortalData's portalPos field, FuncCallContext's call_cntr and max_calls fields, ExecutorRun's count argument, PortalRunFetch's result, and the max number of rows in a SPITupleTable to uint64, and deals with (I hope) all the ensuing fallout. Some of these values were declared uint32 before, and others "long". I also removed PortalData's posOverflow field, since that logic seems pretty useless given that portalPos is now always 64 bits. The user-visible results are that command tags for SELECT etc will correctly report tuple counts larger than 4G, as will plpgsql's GET GET DIAGNOSTICS ... ROW_COUNT command. Queries processing more tuples than that are still not exactly the norm, but they're becoming more common. Most values associated with FETCH/MOVE distances, such as PortalRun's count argument and the count argument of most SPI functions that have one, remain declared as "long". It's not clear whether it would be worth promoting those to int64; but it would definitely be a large dollop of additional API churn on top of this, and it would only help 32-bit platforms which seem relatively less likely to see any benefit. Andreas Scherbaum, reviewed by Christian Ullrich, additional hacking by me
2016-03-12 22:05:10 +01:00
#include <limits.h>
#include <unistd.h>
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
/* postgreSQL stuff */
Split tuple struct defs from htup.h to htup_details.h This reduces unnecessary exposure of other headers through htup.h, which is very widely included by many files. I have chosen to move the function prototypes to the new file as well, because that means htup.h no longer needs to include tupdesc.h. In itself this doesn't have much effect in indirect inclusion of tupdesc.h throughout the tree, because it's also required by execnodes.h; but it's something to explore in the future, and it seemed best to do the htup.h change now while I'm busy with it.
2012-08-30 22:15:44 +02:00
#include "access/htup_details.h"
Fix executor/spi.h to follow our usual conventions for include files, ie, not include postgres.h nor anything else it doesn't directly need. Add #includes to calling files as needed to compensate. Per my proposal of yesterday. This should be noted as a source code change in the 8.4 release notes, since it's likely to require changes in add-on modules.
2009-01-07 14:44:37 +01:00
#include "access/xact.h"
#include "catalog/pg_language.h"
#include "catalog/pg_proc.h"
#include "catalog/pg_type.h"
PL/Perl: Add event trigger support From: Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2013-12-11 14:11:59 +01:00
#include "commands/event_trigger.h"
Replace TupleTableSlot convention for whole-row variables and function results with tuples as ordinary varlena Datums. This commit does not in itself do much for us, except eliminate the horrid memory leak associated with evaluation of whole-row variables. However, it lays the groundwork for allowing composite types as table columns, and perhaps some other useful features as well. Per my proposal of a few days ago.
2004-04-01 23:28:47 +02:00
#include "commands/trigger.h"
#include "executor/spi.h"
Further plperl cleanup: be more paranoid about checking the type of data returned from Perl. Consolidate multiple bits of code to convert a Perl hash to a tuple, and drive the conversion off the keys present in the hash rather than the tuple column names, so we detect error if the hash contains keys it shouldn't. (This means keys not in the hash will silently default to NULL, which seems ok to me.) Fix a bunch of reference-count leaks too.
2004-11-23 01:21:24 +01:00
#include "funcapi.h"
Improve parser so that we can show an error cursor position for errors during parse analysis, not only errors detected in the flex/bison stages. This is per my earlier proposal. This commit includes all the basic infrastructure, but locations are only tracked and reported for errors involving column references, function calls, and operators. More could be done later but this seems like a good set to start with. I've also moved the ReportSyntaxErrorPosition logic out of psql and into libpq, which should make it available to more people --- even within psql this is an improvement because warnings weren't handled by ReportSyntaxErrorPosition.
2006-03-14 23:48:25 +01:00
#include "miscadmin.h"
#include "nodes/makefuncs.h"
#include "parser/parse_type.h"
Add plperl.on_perl_init setting to provide for initializing the perl library on load. Also, handle END blocks in plperl. Database access is disallowed during both these operations, although it might be allowed in END blocks in future. Patch from Tim Bunce.
2010-01-30 02:46:57 +01:00
#include "storage/ipc.h"
Restore SIGFPE handler after initializing PL/Perl. Perl, for some unaccountable reason, believes it's a good idea to reset SIGFPE handling to SIG_IGN. Which wouldn't be a good idea even if it worked; but on some platforms (Linux at least) it doesn't work at all, instead resulting in forced process termination if the signal occurs. Given the lack of other complaints, it seems safe to assume that Perl never actually provokes SIGFPE and so there is no value in the setting anyway. Hence, reset it to our normal handler after initializing Perl. Report, analysis and patch by Andres Freund.
2012-09-05 22:43:37 +02:00
#include "tcop/tcopprot.h"
Fix executor/spi.h to follow our usual conventions for include files, ie, not include postgres.h nor anything else it doesn't directly need. Add #includes to calling files as needed to compensate. Per my proposal of yesterday. This should be noted as a source code change in the 8.4 release notes, since it's likely to require changes in add-on modules.
2009-01-07 14:44:37 +01:00
#include "utils/builtins.h"
Suppress compiler warnings in recent plperl patch. Avoid uselessly expensive lookup of the well-known OID of textout().
2007-12-01 18:58:42 +01:00
#include "utils/fmgroids.h"
Clean up local redeclarations of variables with DLLIMPORT, per report from Magnus that MSVC complains about this.
2006-10-19 20:32:48 +02:00
#include "utils/guc.h"
Fix executor/spi.h to follow our usual conventions for include files, ie, not include postgres.h nor anything else it doesn't directly need. Add #includes to calling files as needed to compensate. Per my proposal of yesterday. This should be noted as a source code change in the 8.4 release notes, since it's likely to require changes in add-on modules.
2009-01-07 14:44:37 +01:00
#include "utils/hsearch.h"
Redesign query-snapshot timing so that volatile functions in READ COMMITTED mode see a fresh snapshot for each command in the function, rather than using the latest interactive command's snapshot. Also, suppress fresh snapshots as well as CommandCounterIncrement inside STABLE and IMMUTABLE functions, instead using the snapshot taken for the most closely nested regular query. (This behavior is only sane for read-only functions, so the patch also enforces that such functions contain only SELECT commands.) As per my proposal of 6-Sep-2004; I note that I floated essentially the same proposal on 19-Jun-2002, but that discussion tailed off without any action. Since 8.0 seems like the right place to be taking possibly nontrivial backwards compatibility hits, let's get it done now.
2004-09-13 22:10:13 +02:00
#include "utils/lsyscache.h"
For some reason access/tupmacs.h has been #including utils/memutils.h, which is neither needed by nor related to that header. Remove the bogus inclusion and instead include the header in those C files that actually need it. Also fix unnecessary inclusions and bad inclusion order in tsearch2 files.
2005-05-06 19:24:55 +02:00
#include "utils/memutils.h"
Move Trigger and TriggerDesc structs out of rel.h into a new reltrigger.h This lets us stop including rel.h into execnodes.h, which is a widely used header.
2011-02-23 18:18:09 +01:00
#include "utils/rel.h"
Fix executor/spi.h to follow our usual conventions for include files, ie, not include postgres.h nor anything else it doesn't directly need. Add #includes to calling files as needed to compensate. Per my proposal of yesterday. This should be noted as a source code change in the 8.4 release notes, since it's likely to require changes in add-on modules.
2009-01-07 14:44:37 +01:00
#include "utils/syscache.h"
Replace TupleTableSlot convention for whole-row variables and function results with tuples as ordinary varlena Datums. This commit does not in itself do much for us, except eliminate the horrid memory leak associated with evaluation of whole-row variables. However, it lays the groundwork for allowing composite types as table columns, and perhaps some other useful features as well. Per my proposal of a few days ago.
2004-04-01 23:28:47 +02:00
#include "utils/typcache.h"
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
Improve translatability of error messages for external modules by tweaking the ereport macro. Included in this commit are enough files for starting plpgsql, plpython, plperl and pltcl translations.
2008-10-09 19:24:05 +02:00
/* define our text domain for translations */
#undef TEXTDOMAIN
Append major version number and for libraries soname major version number to the gettext domain name, to simplify parallel installations. Also, rename set_text_domain() to pg_bindtextdomain(), because that is what it does.
2008-12-11 08:34:09 +01:00
#define TEXTDOMAIN PG_TEXTDOMAIN("plperl")
Improve translatability of error messages for external modules by tweaking the ereport macro. Included in this commit are enough files for starting plpgsql, plpython, plperl and pltcl translations.
2008-10-09 19:24:05 +02:00
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
/* perl stuff */
Tidy up and refactor plperl.c. - Changed MULTIPLICITY check from runtime to compiletime. No loads the large Config module. - Changed plperl_init_interp() to return new interp and not alter the global interp_state - Moved plperl_safe_init() call into check_interp(). - Removed plperl_safe_init_done state variable as interp_state now covers that role. - Changed plperl_create_sub() to take a plperl_proc_desc argument. - Simplified return value handling in plperl_create_sub. - Changed perl.com link in the docs to perl.org and tweaked wording to clarify that require, not use, is what's blocked. - Moved perl code in large multi-line C string literal macros out to plc_*.pl files. - Added a test2macro.pl utility to convert the plc_*.pl files to macros in a perlchunks.h file which is #included - Simplifed plperl_safe_init() slightly - Optimized pg_verifymbstr calls to avoid unneeded strlen()s. Patch from Tim Bunce, with minor editing from me.
2010-01-09 03:40:50 +01:00
/* string literal macros defining chunks of perl code */
#include "perlchunks.h"
Make the order of the header file includes consistent. Similar to commits 14aec03502, 7e735035f2 and dddf4cdc33, this commit makes the order of header file inclusion consistent in more places. Author: Vignesh C Reviewed-by: Amit Kapila Discussion: https://postgr.es/m/CALDaNm2Sznv8RR6Ex-iJO6xAdsxgWhCoETkaYX=+9DW3q0QCfA@mail.gmail.com
2019-11-25 03:38:57 +01:00
#include "plperl.h"
Abandon the use of Perl's Safe.pm to enforce restrictions in plperl, as it is fundamentally insecure. Instead apply an opmask to the whole interpreter that imposes restrictions on unsafe operations. These restrictions are much harder to subvert than is Safe.pm, since there is no container to be broken out of. Backported to release 7.4. In releases 7.4, 8.0 and 8.1 this also includes the necessary backporting of the two interpreters model for plperl and plperlu adopted in release 8.2. In versions 8.0 and up, the use of Perl's POSIX module to undo its locale mangling on Windows has become insecure with these changes, so it is replaced by our own routine, which is also faster. Nice side effects of the changes include that it is now possible to use perl's "strict" pragma in a natural way in plperl, and that perl's $a and $b variables now work as expected in sort routines, and that function compilation is significantly faster. Tim Bunce and Andrew Dunstan, with reviews from Alex Hunsaker and Alexey Klyukin. Security: CVE-2010-1169
2010-05-13 18:39:43 +02:00
/* defines PLPERL_SET_OPMASK */
#include "plperl_opmask.h"
Tidy up and refactor plperl.c. - Changed MULTIPLICITY check from runtime to compiletime. No loads the large Config module. - Changed plperl_init_interp() to return new interp and not alter the global interp_state - Moved plperl_safe_init() call into check_interp(). - Removed plperl_safe_init_done state variable as interp_state now covers that role. - Changed plperl_create_sub() to take a plperl_proc_desc argument. - Simplified return value handling in plperl_create_sub. - Changed perl.com link in the docs to perl.org and tweaked wording to clarify that require, not use, is what's blocked. - Moved perl code in large multi-line C string literal macros out to plc_*.pl files. - Added a test2macro.pl utility to convert the plc_*.pl files to macros in a perlchunks.h file which is #included - Simplifed plperl_safe_init() slightly - Optimized pg_verifymbstr calls to avoid unneeded strlen()s. Patch from Tim Bunce, with minor editing from me.
2010-01-09 03:40:50 +01:00
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
EXTERN_C void boot_DynaLoader(pTHX_ CV *cv);
EXTERN_C void boot_PostgreSQL__InServer__Util(pTHX_ CV *cv);
EXTERN_C void boot_PostgreSQL__InServer__SPI(pTHX_ CV *cv);
Magic blocks don't do us any good unless we use 'em ... so install one in every shared library.
2006-05-31 00:12:16 +02:00
PG_MODULE_MAGIC;
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
/**********************************************************************
pgindent run on plperl.c
2011-02-17 20:40:13 +01:00
* Information associated with a Perl interpreter. We have one interpreter
* that is used for all plperlu (untrusted) functions. For plperl (trusted)
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
* functions, there is a separate interpreter for each effective SQL userid.
* (This is needed to ensure that an unprivileged user can't inject Perl code
* that'll be executed with the privileges of some other SQL user.)
*
* The plperl_interp_desc structs are kept in a Postgres hash table indexed
* by userid OID, with OID 0 used for the single untrusted interpreter.
Make plperl safe against functions that are redefined while running. validate_plperl_function() supposed that it could free an old plperl_proc_desc struct immediately upon detecting that it was stale. However, if a plperl function is called recursively, this could result in deleting the struct out from under an outer invocation, leading to misbehavior or crashes. Add a simple reference-count mechanism to ensure that such structs are freed only when the last reference goes away. Per investigation of bug #7516 from Marko Tiikkaja. I am not certain that this error explains his report, because he says he didn't have any recursive calls --- but it's hard to see how else it could have crashed right there. In any case, this definitely fixes some problems in the area. Back-patch to all active branches.
2012-09-10 02:32:54 +02:00
* Once created, an interpreter is kept for the life of the process.
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
*
* We start out by creating a "held" interpreter, which we initialize
* only as far as we can do without deciding if it will be trusted or
* untrusted. Later, when we first need to run a plperl or plperlu
* function, we complete the initialization appropriately and move the
* PerlInterpreter pointer into the plperl_interp_hash hashtable. If after
* that we need more interpreters, we create them as needed if we can, or
* fail if the Perl build doesn't support multiple interpreters.
*
* The reason for all the dancing about with a held interpreter is to make
* it possible for people to preload a lot of Perl code at postmaster startup
* (using plperl.on_init) and then use that code in backends. Of course this
* will only work for the first interpreter created in any backend, but it's
* still useful with that restriction.
**********************************************************************/
typedef struct plperl_interp_desc
{
pgindent run on plperl.c
2011-02-17 20:40:13 +01:00
Oid user_id; /* Hash key (must be first!) */
PerlInterpreter *interp; /* The interpreter */
HTAB *query_hash; /* plperl_query_entry structs */
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
} plperl_interp_desc;
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
/**********************************************************************
* The information we cache about loaded procedures
Make plperl safe against functions that are redefined while running. validate_plperl_function() supposed that it could free an old plperl_proc_desc struct immediately upon detecting that it was stale. However, if a plperl function is called recursively, this could result in deleting the struct out from under an outer invocation, leading to misbehavior or crashes. Add a simple reference-count mechanism to ensure that such structs are freed only when the last reference goes away. Per investigation of bug #7516 from Marko Tiikkaja. I am not certain that this error explains his report, because he says he didn't have any recursive calls --- but it's hard to see how else it could have crashed right there. In any case, this definitely fixes some problems in the area. Back-patch to all active branches.
2012-09-10 02:32:54 +02:00
*
Improve memory management for PL/Perl functions. Unlike PL/Tcl, PL/Perl at least made an attempt to clean up after itself when a function gets redefined. But it was still using TopMemoryContext for the fn_mcxt of argument/result I/O functions, resulting in the potential for memory leaks depending on what those functions did, and the retail alloc/free logic was pretty bulky as well. Fix things to use a per-function memory context like the other PLs now do. Tweak a couple of places where things were being done in a not-very-safe order (on the principle that a memory leak is better than leaving global state inconsistent after an error). Also make some minor cosmetic adjustments, mostly in field names, to make the code look similar to the way PL/Tcl does now wherever it's essentially the same logic. Michael Paquier and Tom Lane Discussion: <CAB7nPqSOyAsHC6jL24J1B+oK3p=yyNoFU0Vs_B6fd2kdd5g5WQ@mail.gmail.com>
2016-09-01 01:54:58 +02:00
* The fn_refcount field counts the struct's reference from the hash table
* shown below, plus one reference for each function call level that is using
* the struct. We can release the struct, and the associated Perl sub, when
* the fn_refcount goes to zero. Releasing the struct itself is done by
* deleting the fn_cxt, which also gets rid of all subsidiary data.
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
**********************************************************************/
typedef struct plperl_proc_desc
{
Fix plperl and pltcl to include the name of the current function when passing on errors from the language interpreter. (plpython seems fairly OK about this already.) Per gripe from Robert Kleemann.
2007-10-05 19:06:11 +02:00
char *proname; /* user name of procedure */
Improve memory management for PL/Perl functions. Unlike PL/Tcl, PL/Perl at least made an attempt to clean up after itself when a function gets redefined. But it was still using TopMemoryContext for the fn_mcxt of argument/result I/O functions, resulting in the potential for memory leaks depending on what those functions did, and the retail alloc/free logic was pretty bulky as well. Fix things to use a per-function memory context like the other PLs now do. Tweak a couple of places where things were being done in a not-very-safe order (on the principle that a memory leak is better than leaving global state inconsistent after an error). Also make some minor cosmetic adjustments, mostly in field names, to make the code look similar to the way PL/Tcl does now wherever it's essentially the same logic. Michael Paquier and Tom Lane Discussion: <CAB7nPqSOyAsHC6jL24J1B+oK3p=yyNoFU0Vs_B6fd2kdd5g5WQ@mail.gmail.com>
2016-09-01 01:54:58 +02:00
MemoryContext fn_cxt; /* memory context for this procedure */
unsigned long fn_refcount; /* number of active references */
Make plperl safe against functions that are redefined while running. validate_plperl_function() supposed that it could free an old plperl_proc_desc struct immediately upon detecting that it was stale. However, if a plperl function is called recursively, this could result in deleting the struct out from under an outer invocation, leading to misbehavior or crashes. Add a simple reference-count mechanism to ensure that such structs are freed only when the last reference goes away. Per investigation of bug #7516 from Marko Tiikkaja. I am not certain that this error explains his report, because he says he didn't have any recursive calls --- but it's hard to see how else it could have crashed right there. In any case, this definitely fixes some problems in the area. Back-patch to all active branches.
2012-09-10 02:32:54 +02:00
TransactionId fn_xmin; /* xmin/TID of procedure's pg_proc tuple */
Combine cmin and cmax fields of HeapTupleHeaders into a single field, by keeping private state in each backend that has inserted and deleted the same tuple during its current top-level transaction. This is sufficient since there is no need to be able to determine the cmin/cmax from any other transaction. This gets us back down to 23-byte headers, removing a penalty paid in 8.0 to support subtransactions. Patch by Heikki Linnakangas, with minor revisions by moi, following a design hashed out awhile back on the pghackers list.
2007-02-09 04:35:35 +01:00
ItemPointerData fn_tid;
Make plperl safe against functions that are redefined while running. validate_plperl_function() supposed that it could free an old plperl_proc_desc struct immediately upon detecting that it was stale. However, if a plperl function is called recursively, this could result in deleting the struct out from under an outer invocation, leading to misbehavior or crashes. Add a simple reference-count mechanism to ensure that such structs are freed only when the last reference goes away. Per investigation of bug #7516 from Marko Tiikkaja. I am not certain that this error explains his report, because he says he didn't have any recursive calls --- but it's hard to see how else it could have crashed right there. In any case, this definitely fixes some problems in the area. Back-patch to all active branches.
2012-09-10 02:32:54 +02:00
SV *reference; /* CODE reference for Perl sub */
pgindent run on plperl.c
2011-02-17 20:40:13 +01:00
plperl_interp_desc *interp; /* interpreter it's created in */
Make plperl safe against functions that are redefined while running. validate_plperl_function() supposed that it could free an old plperl_proc_desc struct immediately upon detecting that it was stale. However, if a plperl function is called recursively, this could result in deleting the struct out from under an outer invocation, leading to misbehavior or crashes. Add a simple reference-count mechanism to ensure that such structs are freed only when the last reference goes away. Per investigation of bug #7516 from Marko Tiikkaja. I am not certain that this error explains his report, because he says he didn't have any recursive calls --- but it's hard to see how else it could have crashed right there. In any case, this definitely fixes some problems in the area. Back-patch to all active branches.
2012-09-10 02:32:54 +02:00
bool fn_readonly; /* is function readonly (not volatile)? */
Add transforms feature This provides a mechanism for specifying conversions between SQL data types and procedural languages. As examples, there are transforms for hstore and ltree for PL/Perl and PL/Python. reviews by Pavel Stěhule and Andres Freund
2015-04-26 16:33:14 +02:00
Oid lang_oid;
List *trftypes;
Make plperl safe against functions that are redefined while running. validate_plperl_function() supposed that it could free an old plperl_proc_desc struct immediately upon detecting that it was stale. However, if a plperl function is called recursively, this could result in deleting the struct out from under an outer invocation, leading to misbehavior or crashes. Add a simple reference-count mechanism to ensure that such structs are freed only when the last reference goes away. Per investigation of bug #7516 from Marko Tiikkaja. I am not certain that this error explains his report, because he says he didn't have any recursive calls --- but it's hard to see how else it could have crashed right there. In any case, this definitely fixes some problems in the area. Back-patch to all active branches.
2012-09-10 02:32:54 +02:00
bool lanpltrusted; /* is it plperl, rather than plperlu? */
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
bool fn_retistuple; /* true, if function returns tuple */
The attached patch, which incorporates the previous one sent and currently unapplied regarding spi_internal.c, makes some additional fixes relating to return types, and also contains the fix for preventing the use of insecure versions of Safe.pm. There is one remaing return case that does not appear to work, namely return of a composite directly in a select, i.e. if foo returns some composite type, 'select * from foo()' works but 'select foo()' doesn't. We will either fix that or document it as a limitation. The function plperl_func_handler is a mess - I will try to get it cleaned up (and split up) in a subsequent patch, time permitting. Also, reiterating previous advice - this changes slightly the API for spi_exec_query - the returned object has either 2 or 3 members: 'status' (string) and 'proceesed' (int,- number of rows) and, if rows are returned, 'rows' (array of tuple hashes). Andrew Dunstan
2004-07-12 16:31:04 +02:00
bool fn_retisset; /* true, if function returns set */
Following up a previous thought I had, yesterday I realised how to return arays nicely without having to make the plperl programmer aware of anything. The attached patch allows plperl to return an arrayref where the function returns an array type. It silently calls a perl function to stringify the array before passing it to the pg array parser. Non-array returns are handled as before (i.e. passed through this process) so it is backwards compatible. I will presently submit regression tests and docs. example: andrew=# create or replace function blah() returns text[][] language plperl as $$ return [['a"b','c,d'],['e\\f','g']]; $$; CREATE FUNCTION andrew=# select blah(); blah ----------------------------- {{"a\"b","c,d"},{"e\\f",g}} This would complete half of the TODO item: . Pass arrays natively instead of as text between plperl and postgres (The other half is translating pg array arguments to perl arrays - that will have to wait for 8.1). Some of this patch is adapted from a previously submitted patch from Sergej Sergeev. Both he and Abhijit Menon-Sen have looked it over briefly and tentatively said it looks ok. Andrew Dunstan
2005-07-10 17:32:47 +02:00
bool fn_retisarray; /* true if function returns array */
Make plperl safe against functions that are redefined while running. validate_plperl_function() supposed that it could free an old plperl_proc_desc struct immediately upon detecting that it was stale. However, if a plperl function is called recursively, this could result in deleting the struct out from under an outer invocation, leading to misbehavior or crashes. Add a simple reference-count mechanism to ensure that such structs are freed only when the last reference goes away. Per investigation of bug #7516 from Marko Tiikkaja. I am not certain that this error explains his report, because he says he didn't have any recursive calls --- but it's hard to see how else it could have crashed right there. In any case, this definitely fixes some problems in the area. Back-patch to all active branches.
2012-09-10 02:32:54 +02:00
/* Conversion info for function's result type: */
Try to instill some sanity in plperl's function result processing. Get rid of static variables for SETOF result, don't crash when called from non-FROM context, eliminate dead code, etc.
2004-11-22 21:31:53 +01:00
Oid result_oid; /* Oid of result type */
FmgrInfo result_in_func; /* I/O function and arg for result type */
Infrastructure for I/O of composite types: arrange for the I/O routines of a composite type to get that type's OID as their second parameter, in place of typelem which is useless. The actual changes are mostly centralized in getTypeInputInfo and siblings, but I had to fix a few places that were fetching pg_type.typelem for themselves instead of using the lsyscache.c routines. Also, I renamed all the related variables from 'typelem' to 'typioparam' to discourage people from assuming that they necessarily contain array element types.
2004-06-06 02:41:28 +02:00
Oid result_typioparam;
Improve memory management for PL/Perl functions. Unlike PL/Tcl, PL/Perl at least made an attempt to clean up after itself when a function gets redefined. But it was still using TopMemoryContext for the fn_mcxt of argument/result I/O functions, resulting in the potential for memory leaks depending on what those functions did, and the retail alloc/free logic was pretty bulky as well. Fix things to use a per-function memory context like the other PLs now do. Tweak a couple of places where things were being done in a not-very-safe order (on the principle that a memory leak is better than leaving global state inconsistent after an error). Also make some minor cosmetic adjustments, mostly in field names, to make the code look similar to the way PL/Tcl does now wherever it's essentially the same logic. Michael Paquier and Tom Lane Discussion: <CAB7nPqSOyAsHC6jL24J1B+oK3p=yyNoFU0Vs_B6fd2kdd5g5WQ@mail.gmail.com>
2016-09-01 01:54:58 +02:00
/* Per-argument info for function's argument types: */
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
int nargs;
Improve memory management for PL/Perl functions. Unlike PL/Tcl, PL/Perl at least made an attempt to clean up after itself when a function gets redefined. But it was still using TopMemoryContext for the fn_mcxt of argument/result I/O functions, resulting in the potential for memory leaks depending on what those functions did, and the retail alloc/free logic was pretty bulky as well. Fix things to use a per-function memory context like the other PLs now do. Tweak a couple of places where things were being done in a not-very-safe order (on the principle that a memory leak is better than leaving global state inconsistent after an error). Also make some minor cosmetic adjustments, mostly in field names, to make the code look similar to the way PL/Tcl does now wherever it's essentially the same logic. Michael Paquier and Tom Lane Discussion: <CAB7nPqSOyAsHC6jL24J1B+oK3p=yyNoFU0Vs_B6fd2kdd5g5WQ@mail.gmail.com>
2016-09-01 01:54:58 +02:00
FmgrInfo *arg_out_func; /* output fns for arg types */
bool *arg_is_rowtype; /* is each arg composite? */
Oid *arg_arraytype; /* InvalidOid if not an array */
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
} plperl_proc_desc;
Make plperl safe against functions that are redefined while running. validate_plperl_function() supposed that it could free an old plperl_proc_desc struct immediately upon detecting that it was stale. However, if a plperl function is called recursively, this could result in deleting the struct out from under an outer invocation, leading to misbehavior or crashes. Add a simple reference-count mechanism to ensure that such structs are freed only when the last reference goes away. Per investigation of bug #7516 from Marko Tiikkaja. I am not certain that this error explains his report, because he says he didn't have any recursive calls --- but it's hard to see how else it could have crashed right there. In any case, this definitely fixes some problems in the area. Back-patch to all active branches.
2012-09-10 02:32:54 +02:00
#define increment_prodesc_refcount(prodesc) \
Improve memory management for PL/Perl functions. Unlike PL/Tcl, PL/Perl at least made an attempt to clean up after itself when a function gets redefined. But it was still using TopMemoryContext for the fn_mcxt of argument/result I/O functions, resulting in the potential for memory leaks depending on what those functions did, and the retail alloc/free logic was pretty bulky as well. Fix things to use a per-function memory context like the other PLs now do. Tweak a couple of places where things were being done in a not-very-safe order (on the principle that a memory leak is better than leaving global state inconsistent after an error). Also make some minor cosmetic adjustments, mostly in field names, to make the code look similar to the way PL/Tcl does now wherever it's essentially the same logic. Michael Paquier and Tom Lane Discussion: <CAB7nPqSOyAsHC6jL24J1B+oK3p=yyNoFU0Vs_B6fd2kdd5g5WQ@mail.gmail.com>
2016-09-01 01:54:58 +02:00
((prodesc)->fn_refcount++)
Make plperl safe against functions that are redefined while running. validate_plperl_function() supposed that it could free an old plperl_proc_desc struct immediately upon detecting that it was stale. However, if a plperl function is called recursively, this could result in deleting the struct out from under an outer invocation, leading to misbehavior or crashes. Add a simple reference-count mechanism to ensure that such structs are freed only when the last reference goes away. Per investigation of bug #7516 from Marko Tiikkaja. I am not certain that this error explains his report, because he says he didn't have any recursive calls --- but it's hard to see how else it could have crashed right there. In any case, this definitely fixes some problems in the area. Back-patch to all active branches.
2012-09-10 02:32:54 +02:00
#define decrement_prodesc_refcount(prodesc) \
do { \
Improve memory management for PL/Perl functions. Unlike PL/Tcl, PL/Perl at least made an attempt to clean up after itself when a function gets redefined. But it was still using TopMemoryContext for the fn_mcxt of argument/result I/O functions, resulting in the potential for memory leaks depending on what those functions did, and the retail alloc/free logic was pretty bulky as well. Fix things to use a per-function memory context like the other PLs now do. Tweak a couple of places where things were being done in a not-very-safe order (on the principle that a memory leak is better than leaving global state inconsistent after an error). Also make some minor cosmetic adjustments, mostly in field names, to make the code look similar to the way PL/Tcl does now wherever it's essentially the same logic. Michael Paquier and Tom Lane Discussion: <CAB7nPqSOyAsHC6jL24J1B+oK3p=yyNoFU0Vs_B6fd2kdd5g5WQ@mail.gmail.com>
2016-09-01 01:54:58 +02:00
Assert((prodesc)->fn_refcount > 0); \
if (--((prodesc)->fn_refcount) == 0) \
Make plperl safe against functions that are redefined while running. validate_plperl_function() supposed that it could free an old plperl_proc_desc struct immediately upon detecting that it was stale. However, if a plperl function is called recursively, this could result in deleting the struct out from under an outer invocation, leading to misbehavior or crashes. Add a simple reference-count mechanism to ensure that such structs are freed only when the last reference goes away. Per investigation of bug #7516 from Marko Tiikkaja. I am not certain that this error explains his report, because he says he didn't have any recursive calls --- but it's hard to see how else it could have crashed right there. In any case, this definitely fixes some problems in the area. Back-patch to all active branches.
2012-09-10 02:32:54 +02:00
free_plperl_function(prodesc); \
} while(0)
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
/**********************************************************************
* For speedy lookup, we maintain a hash table mapping from
Revert removal of trigger flag from plperl function hash key. As noted by Jan Urbanski, this flag is in fact needed to ensure that the function's input/result conversion functions are set up as expected. Add a regression test to discourage anyone from making same mistake in future.
2010-10-31 16:42:51 +01:00
* function OID + trigger flag + user OID to plperl_proc_desc pointers.
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
* The reason the plperl_proc_desc struct isn't directly part of the hash
* entry is to simplify recovery from errors during compile_plperl_function.
*
* Note: if the same function is called by multiple userIDs within a session,
* there will be a separate plperl_proc_desc entry for each userID in the case
* of plperl functions, but only one entry for plperlu functions, because we
* set user_id = 0 for that case. If the user redeclares the same function
* from plperl to plperlu or vice versa, there might be multiple
* plperl_proc_ptr entries in the hashtable, but only one is valid.
**********************************************************************/
typedef struct plperl_proc_key
{
pgindent run on plperl.c
2011-02-17 20:40:13 +01:00
Oid proc_id; /* Function OID */
Revert removal of trigger flag from plperl function hash key. As noted by Jan Urbanski, this flag is in fact needed to ensure that the function's input/result conversion functions are set up as expected. Add a regression test to discourage anyone from making same mistake in future.
2010-10-31 16:42:51 +01:00
/*
* is_trigger is really a bool, but declare as Oid to ensure this struct
* contains no padding
*/
pgindent run on plperl.c
2011-02-17 20:40:13 +01:00
Oid is_trigger; /* is it a trigger function? */
Oid user_id; /* User calling the function, or 0 */
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
} plperl_proc_key;
Force plperl and plperlu to run in separate interpreters. Create an error on an attempt to create the second interpreter if this is not supported by the perl installation. Per recent -hackers discussion.
2006-11-13 18:13:57 +01:00
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
typedef struct plperl_proc_ptr
Force plperl and plperlu to run in separate interpreters. Create an error on an attempt to create the second interpreter if this is not supported by the perl installation. Per recent -hackers discussion.
2006-11-13 18:13:57 +01:00
{
pgindent run on plperl.c
2011-02-17 20:40:13 +01:00
plperl_proc_key proc_key; /* Hash key (must be first!) */
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
plperl_proc_desc *proc_ptr;
} plperl_proc_ptr;
Force plperl and plperlu to run in separate interpreters. Create an error on an attempt to create the second interpreter if this is not supported by the perl installation. Per recent -hackers discussion.
2006-11-13 18:13:57 +01:00
Per a bug report from Theo Schlossnagle, plperl_return_next() leaks memory in the executor's per-query memory context. It also inefficient: it invokes get_call_result_type() and TupleDescGetAttInMetadata() for every call to return_next, rather than invoking them once (per PL/Perl function call) and memoizing the result. This patch makes the following changes: - refactor the code to include all the "per PL/Perl function call" data inside a single struct, "current_call_data". This means we don't need to save and restore N pointers for every recursive call into PL/Perl, we can just save and restore one. - lookup the return type metadata needed by plperl_return_next() once, and then stash it in "current_call_data", so as to avoid doing the lookup for every call to return_next. - create a temporary memory context in which to evaluate the return type's input functions. This memory context is reset for each call to return_next. The patch appears to fix the memory leak, and substantially reduces the overhead imposed by return_next.
2006-01-28 04:28:15 +01:00
/*
* The information we cache for the duration of a single call to a
* function.
*/
typedef struct plperl_call_data
{
plperl_proc_desc *prodesc;
FunctionCallInfo fcinfo;
Support domains over composite types in PL/Perl. In passing, don't insist on rsi->expectedDesc being set unless we actually need it; this allows succeeding in a couple of cases where PL/Perl functions returning setof composite would have failed before, and makes the error message more apropos in other cases. Discussion: https://postgr.es/m/4206.1499798337@sss.pgh.pa.us
2017-10-28 20:02:21 +02:00
/* remaining fields are used only in a function returning set: */
Per a bug report from Theo Schlossnagle, plperl_return_next() leaks memory in the executor's per-query memory context. It also inefficient: it invokes get_call_result_type() and TupleDescGetAttInMetadata() for every call to return_next, rather than invoking them once (per PL/Perl function call) and memoizing the result. This patch makes the following changes: - refactor the code to include all the "per PL/Perl function call" data inside a single struct, "current_call_data". This means we don't need to save and restore N pointers for every recursive call into PL/Perl, we can just save and restore one. - lookup the return type metadata needed by plperl_return_next() once, and then stash it in "current_call_data", so as to avoid doing the lookup for every call to return_next. - create a temporary memory context in which to evaluate the return type's input functions. This memory context is reset for each call to return_next. The patch appears to fix the memory leak, and substantially reduces the overhead imposed by return_next.
2006-01-28 04:28:15 +01:00
Tuplestorestate *tuple_store;
TupleDesc ret_tdesc;
Support domains over composite types in PL/Perl. In passing, don't insist on rsi->expectedDesc being set unless we actually need it; this allows succeeding in a couple of cases where PL/Perl functions returning setof composite would have failed before, and makes the error message more apropos in other cases. Discussion: https://postgr.es/m/4206.1499798337@sss.pgh.pa.us
2017-10-28 20:02:21 +02:00
Oid cdomain_oid; /* 0 unless returning domain-over-composite */
void *cdomain_info;
Per a bug report from Theo Schlossnagle, plperl_return_next() leaks memory in the executor's per-query memory context. It also inefficient: it invokes get_call_result_type() and TupleDescGetAttInMetadata() for every call to return_next, rather than invoking them once (per PL/Perl function call) and memoizing the result. This patch makes the following changes: - refactor the code to include all the "per PL/Perl function call" data inside a single struct, "current_call_data". This means we don't need to save and restore N pointers for every recursive call into PL/Perl, we can just save and restore one. - lookup the return type metadata needed by plperl_return_next() once, and then stash it in "current_call_data", so as to avoid doing the lookup for every call to return_next. - create a temporary memory context in which to evaluate the return type's input functions. This memory context is reset for each call to return_next. The patch appears to fix the memory leak, and substantially reduces the overhead imposed by return_next.
2006-01-28 04:28:15 +01:00
MemoryContext tmp_cxt;
} plperl_call_data;
Prepared queries for PLPerl, plus fixing a small plperl memory leak. Patch and docs from Dmitry Karasik, slightly editorialised.
2006-03-05 17:40:51 +01:00
/**********************************************************************
* The information we cache about prepared and saved plans
**********************************************************************/
typedef struct plperl_query_desc
{
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
char qname[24];
Eliminate memory leaks in plperl's spi_prepare() function. Careless use of TopMemoryContext for I/O function data meant that repeated use of spi_prepare and spi_freeplan would leak memory at the session level, as per report from Christian Schröder. In addition, spi_prepare leaked a lot of transient data within the current plperl function's SPI Proc context, which would be a problem for repeated use of spi_prepare within a single plperl function call; and it wasn't terribly careful about releasing permanent allocations in event of an error, either. In passing, clean up some copy-and-pasteos in query-lookup error messages. Alex Hunsaker and Tom Lane
2013-03-02 03:33:34 +01:00
MemoryContext plan_cxt; /* context holding this struct */
Redesign the plancache mechanism for more flexibility and efficiency. Rewrite plancache.c so that a "cached plan" (which is rather a misnomer at this point) can support generation of custom, parameter-value-dependent plans, and can make an intelligent choice between using custom plans and the traditional generic-plan approach. The specific choice algorithm implemented here can probably be improved in future, but this commit is all about getting the mechanism in place, not the policy. In addition, restructure the API to greatly reduce the amount of extraneous data copying needed. The main compromise needed to make that possible was to split the initial creation of a CachedPlanSource into two steps. It's worth noting in particular that SPI_saveplan is now deprecated in favor of SPI_keepplan, which accomplishes the same end result with zero data copying, and no need to then spend even more cycles throwing away the original SPIPlan. The risk of long-term memory leaks while manipulating SPIPlans has also been greatly reduced. Most of this improvement is based on use of the recently-added MemoryContextSetParent primitive.
2011-09-16 06:42:53 +02:00
SPIPlanPtr plan;
Prepared queries for PLPerl, plus fixing a small plperl memory leak. Patch and docs from Dmitry Karasik, slightly editorialised.
2006-03-05 17:40:51 +01:00
int nargs;
Oid *argtypes;
FmgrInfo *arginfuncs;
Oid *argtypioparams;
} plperl_query_desc;
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
Force plperl and plperlu to run in separate interpreters. Create an error on an attempt to create the second interpreter if this is not supported by the perl installation. Per recent -hackers discussion.
2006-11-13 18:13:57 +01:00
/* hash table entry for query desc */
typedef struct plperl_query_entry
{
char query_name[NAMEDATALEN];
plperl_query_desc *query_data;
} plperl_query_entry;
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
/**********************************************************************
* Information for PostgreSQL - Perl array conversion.
**********************************************************************/
typedef struct plperl_array_info
{
int ndims;
bool elem_is_rowtype; /* 't' if element type is a rowtype */
Datum *elements;
bool *nulls;
int *nelems;
FmgrInfo proc;
Add transforms feature This provides a mechanism for specifying conversions between SQL data types and procedural languages. As examples, there are transforms for hstore and ltree for PL/Perl and PL/Python. reviews by Pavel Stěhule and Andres Freund
2015-04-26 16:33:14 +02:00
FmgrInfo transform_proc;
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
} plperl_array_info;
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
/**********************************************************************
* Global data
**********************************************************************/
Force plperl and plperlu to run in separate interpreters. Create an error on an attempt to create the second interpreter if this is not supported by the perl installation. Per recent -hackers discussion.
2006-11-13 18:13:57 +01:00
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
static HTAB *plperl_interp_hash = NULL;
Force plperl and plperlu to run in separate interpreters. Create an error on an attempt to create the second interpreter if this is not supported by the perl installation. Per recent -hackers discussion.
2006-11-13 18:13:57 +01:00
static HTAB *plperl_proc_hash = NULL;
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
static plperl_interp_desc *plperl_active_interp = NULL;
pgindent run on plperl.c
2011-02-17 20:40:13 +01:00
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
/* If we have an unassigned "held" interpreter, it's stored here */
static PerlInterpreter *plperl_held_interp = NULL;
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
/* GUC variables */
At 2005-05-21 20:18:50 +0530, ams@oryx.com wrote: > > > The second issue is where plperl returns a large result set. I have attached the following seven patches to address this problem: 1. Trivial. Replaces some errant spaces with tabs. 2. Trivial. Fixes the spelling of Jan's name, and gets rid of many inane, useless, annoying, and often misleading comments. Here's a sample: "plperl_init_all() - Initialize all". (I have tried to add some useful comments here and there, and will continue to do so now and again.) 3. Trivial. Splits up some long lines. 4. Converts SRFs in PL/Perl to use a Tuplestore and SFRM_Materialize to return the result set, based on the PL/PgSQL model. There are two major consequences: result sets will spill to disk when they can no longer fit in work_mem; and "select foo_srf()" no longer works. (I didn't lose sleep over the latter, since that form is not valid in PL/PgSQL, and it's not documented in PL/Perl.) 5. Trivial, but important. Fixes use of "undef" instead of undef. This would cause empty functions to fail in bizarre ways. I suspect that there's still another (old) bug here. I'll investigate further. 6. Moves the majority of (4) out into a new plperl_return_next() function, to make it possible to expose the functionality to Perl; cleans up some of the code besides. 7. Add an spi_return_next function for use in Perl code. If you want to apply the patches and try them out, 8-composite.diff is what you should use. (Note: my patches depend upon Andrew's use-strict and %_SHARED patches being applied.) Here's something to try: create or replace function foo() returns setof record as $$ $i = 0; for ("World", "PostgreSQL", "PL/Perl") { spi_return_next({f1=>++$i, f2=>'Hello', f3=>$_}); } return; $$ language plperl; select * from foo() as (f1 integer, f2 text, f3 text); (Many thanks to Andrews Dunstan and Supernews for their help.) Abhijit Menon-Sen
2005-06-04 22:33:06 +02:00
static bool plperl_use_strict = false;
Add plperl.on_plperl_init and plperl.on_plperlu_init settings for language-specific startup. Rename recently added plperl.on_perl_init to plperl.on_init. Also, code cleanup for utf8 hack. Patch from Tim Bunce, reviewed by Alex Hunsaker.
2010-02-12 20:35:25 +01:00
static char *plperl_on_init = NULL;
static char *plperl_on_plperl_init = NULL;
static char *plperl_on_plperlu_init = NULL;
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
Add plperl.on_perl_init setting to provide for initializing the perl library on load. Also, handle END blocks in plperl. Database access is disallowed during both these operations, although it might be allowed in END blocks in future. Patch from Tim Bunce.
2010-01-30 02:46:57 +01:00
static bool plperl_ending = false;
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
static OP *(*pp_require_orig) (pTHX) = NULL;
Abandon the use of Perl's Safe.pm to enforce restrictions in plperl, as it is fundamentally insecure. Instead apply an opmask to the whole interpreter that imposes restrictions on unsafe operations. These restrictions are much harder to subvert than is Safe.pm, since there is no container to be broken out of. Backported to release 7.4. In releases 7.4, 8.0 and 8.1 this also includes the necessary backporting of the two interpreters model for plperl and plperlu adopted in release 8.2. In versions 8.0 and up, the use of Perl's POSIX module to undo its locale mangling on Windows has become insecure with these changes, so it is replaced by our own routine, which is also faster. Nice side effects of the changes include that it is now possible to use perl's "strict" pragma in a natural way in plperl, and that perl's $a and $b variables now work as expected in sort routines, and that function compilation is significantly faster. Tim Bunce and Andrew Dunstan, with reviews from Alex Hunsaker and Alexey Klyukin. Security: CVE-2010-1169
2010-05-13 18:39:43 +02:00
static char plperl_opmask[MAXO];
At 2005-05-21 20:18:50 +0530, ams@oryx.com wrote: > > > The second issue is where plperl returns a large result set. I have attached the following seven patches to address this problem: 1. Trivial. Replaces some errant spaces with tabs. 2. Trivial. Fixes the spelling of Jan's name, and gets rid of many inane, useless, annoying, and often misleading comments. Here's a sample: "plperl_init_all() - Initialize all". (I have tried to add some useful comments here and there, and will continue to do so now and again.) 3. Trivial. Splits up some long lines. 4. Converts SRFs in PL/Perl to use a Tuplestore and SFRM_Materialize to return the result set, based on the PL/PgSQL model. There are two major consequences: result sets will spill to disk when they can no longer fit in work_mem; and "select foo_srf()" no longer works. (I didn't lose sleep over the latter, since that form is not valid in PL/PgSQL, and it's not documented in PL/Perl.) 5. Trivial, but important. Fixes use of "undef" instead of undef. This would cause empty functions to fail in bizarre ways. I suspect that there's still another (old) bug here. I'll investigate further. 6. Moves the majority of (4) out into a new plperl_return_next() function, to make it possible to expose the functionality to Perl; cleans up some of the code besides. 7. Add an spi_return_next function for use in Perl code. If you want to apply the patches and try them out, 8-composite.diff is what you should use. (Note: my patches depend upon Andrew's use-strict and %_SHARED patches being applied.) Here's something to try: create or replace function foo() returns setof record as $$ $i = 0; for ("World", "PostgreSQL", "PL/Perl") { spi_return_next({f1=>++$i, f2=>'Hello', f3=>$_}); } return; $$ language plperl; select * from foo() as (f1 integer, f2 text, f3 text); (Many thanks to Andrews Dunstan and Supernews for their help.) Abhijit Menon-Sen
2005-06-04 22:33:06 +02:00
Per a bug report from Theo Schlossnagle, plperl_return_next() leaks memory in the executor's per-query memory context. It also inefficient: it invokes get_call_result_type() and TupleDescGetAttInMetadata() for every call to return_next, rather than invoking them once (per PL/Perl function call) and memoizing the result. This patch makes the following changes: - refactor the code to include all the "per PL/Perl function call" data inside a single struct, "current_call_data". This means we don't need to save and restore N pointers for every recursive call into PL/Perl, we can just save and restore one. - lookup the return type metadata needed by plperl_return_next() once, and then stash it in "current_call_data", so as to avoid doing the lookup for every call to return_next. - create a temporary memory context in which to evaluate the return type's input functions. This memory context is reset for each call to return_next. The patch appears to fix the memory leak, and substantially reduces the overhead imposed by return_next.
2006-01-28 04:28:15 +01:00
/* this is saved and restored by plperl_call_handler */
static plperl_call_data *current_call_data = NULL;
Redesign query-snapshot timing so that volatile functions in READ COMMITTED mode see a fresh snapshot for each command in the function, rather than using the latest interactive command's snapshot. Also, suppress fresh snapshots as well as CommandCounterIncrement inside STABLE and IMMUTABLE functions, instead using the snapshot taken for the most closely nested regular query. (This behavior is only sane for read-only functions, so the patch also enforces that such functions contain only SELECT commands.) As per my proposal of 6-Sep-2004; I note that I floated essentially the same proposal on 19-Jun-2002, but that discussion tailed off without any action. Since 8.0 seems like the right place to be taking possibly nontrivial backwards compatibility hits, let's get it done now.
2004-09-13 22:10:13 +02:00
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
/**********************************************************************
* Forward declarations
**********************************************************************/
Add a feature for automatic initialization and finalization of dynamically loaded libraries: call functions _PG_init() and _PG_fini() if the library defines such symbols. Hence we no longer need to specify an initialization function in preload_libraries: we can assume that the library used the _PG_init() convention, instead. This removes one source of pilot error in use of preloaded libraries. Original patch by Ralf Engelschall, preload_libraries changes by me.
2006-08-08 21:15:09 +02:00
Tidy up and refactor plperl.c. - Changed MULTIPLICITY check from runtime to compiletime. No loads the large Config module. - Changed plperl_init_interp() to return new interp and not alter the global interp_state - Moved plperl_safe_init() call into check_interp(). - Removed plperl_safe_init_done state variable as interp_state now covers that role. - Changed plperl_create_sub() to take a plperl_proc_desc argument. - Simplified return value handling in plperl_create_sub. - Changed perl.com link in the docs to perl.org and tweaked wording to clarify that require, not use, is what's blocked. - Moved perl code in large multi-line C string literal macros out to plc_*.pl files. - Added a test2macro.pl utility to convert the plc_*.pl files to macros in a perlchunks.h file which is #included - Simplifed plperl_safe_init() slightly - Optimized pg_verifymbstr calls to avoid unneeded strlen()s. Patch from Tim Bunce, with minor editing from me.
2010-01-09 03:40:50 +01:00
static PerlInterpreter *plperl_init_interp(void);
Add plperl.on_perl_init setting to provide for initializing the perl library on load. Also, handle END blocks in plperl. Database access is disallowed during both these operations, although it might be allowed in END blocks in future. Patch from Tim Bunce.
2010-01-30 02:46:57 +01:00
static void plperl_destroy_interp(PerlInterpreter **);
static void plperl_fini(int code, Datum arg);
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
static void set_interp_require(bool trusted);
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
First round of changes for new fmgr interface. fmgr itself and the key call sites are changed, but most called functions are still oldstyle. An exception is that the PL managers are updated (so, for example, NULL handling now behaves as expected in plperl and plpgsql functions). NOTE initdb is forced due to added column in pg_proc.
2000-05-28 19:56:29 +02:00
static Datum plperl_func_handler(PG_FUNCTION_ARGS);
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
static Datum plperl_trigger_handler(PG_FUNCTION_ARGS);
PL/Perl: Add event trigger support From: Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2013-12-11 14:11:59 +01:00
static void plperl_event_trigger_handler(PG_FUNCTION_ARGS);
Ensure the previous Perl interpreter selection is restored upon exit from plperl_call_handler, in both the normal and error-exit paths. Per report from Alexey Klyukin.
2009-10-31 19:11:59 +01:00
Make plperl safe against functions that are redefined while running. validate_plperl_function() supposed that it could free an old plperl_proc_desc struct immediately upon detecting that it was stale. However, if a plperl function is called recursively, this could result in deleting the struct out from under an outer invocation, leading to misbehavior or crashes. Add a simple reference-count mechanism to ensure that such structs are freed only when the last reference goes away. Per investigation of bug #7516 from Marko Tiikkaja. I am not certain that this error explains his report, because he says he didn't have any recursive calls --- but it's hard to see how else it could have crashed right there. In any case, this definitely fixes some problems in the area. Back-patch to all active branches.
2012-09-10 02:32:54 +02:00
static void free_plperl_function(plperl_proc_desc *prodesc);
PL/Perl: Add event trigger support From: Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2013-12-11 14:11:59 +01:00
static plperl_proc_desc *compile_plperl_function(Oid fn_oid,
bool is_trigger,
bool is_event_trigger);
Fix plperl to discard cached function definition after CREATE OR REPLACE FUNCTION. Clean up typlen/typmod errors inherited from pltcl.
2001-10-20 00:43:49 +02:00
Generated columns This is an SQL-standard feature that allows creating columns that are computed from expressions rather than assigned, similar to a view or materialized view but on a column basis. This implements one kind of generated column: stored (computed on write). Another kind, virtual (computed on read), is planned for the future, and some room is left for it. Reviewed-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Pavel Stehule <pavel.stehule@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/b151f851-4019-bdb1-699e-ebab07d2f40a@2ndquadrant.com
2019-03-30 08:13:09 +01:00
static SV *plperl_hash_from_tuple(HeapTuple tuple, TupleDesc tupdesc, bool include_generated);
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
static SV *plperl_hash_from_datum(Datum attr);
Disallow execution of SPI functions during plperl function compilation. Perl can be convinced to execute user-defined code during compilation of a plperl function (or at least a plperlu function). That's not such a big problem as long as the activity is confined within the Perl interpreter, and it's not clear we could do anything about that anyway. However, if such code tries to use plperl's SPI functions, we have a bigger problem. In the first place, those functions are likely to crash because current_call_data->prodesc isn't set up yet. In the second place, because it isn't set up, we lack critical info such as whether the function is supposed to be read-only. And in the third place, this path allows code execution during function validation, which is strongly discouraged because of the potential for security exploits. Hence, reject execution of the SPI functions until compilation is finished. While here, add check_spi_usage_allowed() calls to various functions that hadn't gotten the memo about checking that. I think that perhaps plperl_sv_to_literal may have been intentionally omitted on the grounds that it was safe at the time; but if so, the addition of transforms functionality changed that. The others are more recently added and seem to be flat-out oversights. Per report from Mark Murawski. Back-patch to all supported branches. Discussion: https://postgr.es/m/9acdf918-7fff-4f40-f750-2ffa84f083d2@intellasoft.net
2022-02-25 23:40:21 +01:00
static void check_spi_usage_allowed(void);
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
static SV *plperl_ref_from_pg_array(Datum arg, Oid typid);
static SV *split_array(plperl_array_info *info, int first, int last, int nest);
static SV *make_array_ref(plperl_array_info *info, int first, int last);
static SV *get_perl_array_ref(SV *sv);
Fix up Perl-to-Postgres datatype conversions in pl/perl. This patch restores the pre-9.1 behavior that pl/perl functions returning VOID ignore the result value of their last Perl statement. 9.1.0 unintentionally threw an error if the last statement returned a reference, as reported by Amit Khandekar. Also, make sure it works to return a string value for a composite type, so long as the string meets the type's input format. We already allowed the equivalent behavior for arrays, so it seems inconsistent to not allow it for composites. In addition, ensure we throw errors for attempts to return arrays or hashes when the function's declared result type is not an array or composite type, respectively. Pre-9.1 versions rather uselessly returned strings like ARRAY(0x221a9a0) or HASH(0x221aa90), while 9.1.0 threw an error for the hash case and returned a garbage value for the array case. Also, clean up assorted grotty coding in Perl array conversion, including use of a session-lifespan memory context to accumulate the array value (resulting in session-lifespan memory leak on error), failure to apply the declared typmod if any, and failure to detect some cases of non-rectangular multi-dimensional arrays. Alex Hunsaker and Tom Lane
2011-10-14 00:02:43 +02:00
static Datum plperl_sv_to_datum(SV *sv, Oid typid, int32 typmod,
FunctionCallInfo fcinfo,
FmgrInfo *finfo, Oid typioparam,
bool *isnull);
static void _sv_to_datum_finfo(Oid typid, FmgrInfo *finfo, Oid *typioparam);
static Datum plperl_array_to_datum(SV *src, Oid typid, int32 typmod);
Tighten array dimensionality checks in Perl -> SQL array conversion. plperl_array_to_datum() wasn't sufficiently careful about checking that nested lists represent a rectangular array structure; it would accept inputs such as "[1, []]". This is a bit related to the PL/Python bug fixed in commit 81eaaf65e, but it doesn't seem to provide any direct route to a memory stomp. Instead the likely failure mode is for makeMdArrayResult to be passed fewer Datums than the claimed array dimensionality requires, possibly leading to a wild pointer dereference and SIGSEGV. Per report from Alexander Lakhin. It's been broken for a long time, so back-patch to all supported branches. Discussion: https://postgr.es/m/5ebae5e4-d401-fadf-8585-ac3eaf53219c@gmail.com
2023-04-29 19:06:44 +02:00
static void array_to_datum_internal(AV *av, ArrayBuildState **astatep,
Fix up Perl-to-Postgres datatype conversions in pl/perl. This patch restores the pre-9.1 behavior that pl/perl functions returning VOID ignore the result value of their last Perl statement. 9.1.0 unintentionally threw an error if the last statement returned a reference, as reported by Amit Khandekar. Also, make sure it works to return a string value for a composite type, so long as the string meets the type's input format. We already allowed the equivalent behavior for arrays, so it seems inconsistent to not allow it for composites. In addition, ensure we throw errors for attempts to return arrays or hashes when the function's declared result type is not an array or composite type, respectively. Pre-9.1 versions rather uselessly returned strings like ARRAY(0x221a9a0) or HASH(0x221aa90), while 9.1.0 threw an error for the hash case and returned a garbage value for the array case. Also, clean up assorted grotty coding in Perl array conversion, including use of a session-lifespan memory context to accumulate the array value (resulting in session-lifespan memory leak on error), failure to apply the declared typmod if any, and failure to detect some cases of non-rectangular multi-dimensional arrays. Alex Hunsaker and Tom Lane
2011-10-14 00:02:43 +02:00
int *ndims, int *dims, int cur_depth,
Tighten array dimensionality checks in Perl -> SQL array conversion. plperl_array_to_datum() wasn't sufficiently careful about checking that nested lists represent a rectangular array structure; it would accept inputs such as "[1, []]". This is a bit related to the PL/Python bug fixed in commit 81eaaf65e, but it doesn't seem to provide any direct route to a memory stomp. Instead the likely failure mode is for makeMdArrayResult to be passed fewer Datums than the claimed array dimensionality requires, possibly leading to a wild pointer dereference and SIGSEGV. Per report from Alexander Lakhin. It's been broken for a long time, so back-patch to all supported branches. Discussion: https://postgr.es/m/5ebae5e4-d401-fadf-8585-ac3eaf53219c@gmail.com
2023-04-29 19:06:44 +02:00
Oid elemtypid, int32 typmod,
Fix up Perl-to-Postgres datatype conversions in pl/perl. This patch restores the pre-9.1 behavior that pl/perl functions returning VOID ignore the result value of their last Perl statement. 9.1.0 unintentionally threw an error if the last statement returned a reference, as reported by Amit Khandekar. Also, make sure it works to return a string value for a composite type, so long as the string meets the type's input format. We already allowed the equivalent behavior for arrays, so it seems inconsistent to not allow it for composites. In addition, ensure we throw errors for attempts to return arrays or hashes when the function's declared result type is not an array or composite type, respectively. Pre-9.1 versions rather uselessly returned strings like ARRAY(0x221a9a0) or HASH(0x221aa90), while 9.1.0 threw an error for the hash case and returned a garbage value for the array case. Also, clean up assorted grotty coding in Perl array conversion, including use of a session-lifespan memory context to accumulate the array value (resulting in session-lifespan memory leak on error), failure to apply the declared typmod if any, and failure to detect some cases of non-rectangular multi-dimensional arrays. Alex Hunsaker and Tom Lane
2011-10-14 00:02:43 +02:00
FmgrInfo *finfo, Oid typioparam);
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
static Datum plperl_hash_to_datum(SV *src, TupleDesc td);
Tweak plperl.c to compile against threaded Perls, per report from cturner@redhat.com.
2002-01-24 22:40:44 +01:00
static void plperl_init_shared_libs(pTHX);
Add plperl.on_plperl_init and plperl.on_plperlu_init settings for language-specific startup. Rename recently added plperl.on_perl_init to plperl.on_init. Also, code cleanup for utf8 hack. Patch from Tim Bunce, reviewed by Alex Hunsaker.
2010-02-12 20:35:25 +01:00
static void plperl_trusted_init(void);
static void plperl_untrusted_init(void);
Widen query numbers-of-tuples-processed counters to uint64. This patch widens SPI_processed, EState's es_processed field, PortalData's portalPos field, FuncCallContext's call_cntr and max_calls fields, ExecutorRun's count argument, PortalRunFetch's result, and the max number of rows in a SPITupleTable to uint64, and deals with (I hope) all the ensuing fallout. Some of these values were declared uint32 before, and others "long". I also removed PortalData's posOverflow field, since that logic seems pretty useless given that portalPos is now always 64 bits. The user-visible results are that command tags for SELECT etc will correctly report tuple counts larger than 4G, as will plpgsql's GET GET DIAGNOSTICS ... ROW_COUNT command. Queries processing more tuples than that are still not exactly the norm, but they're becoming more common. Most values associated with FETCH/MOVE distances, such as PortalRun's count argument and the count argument of most SPI functions that have one, remain declared as "long". It's not clear whether it would be worth promoting those to int64; but it would definitely be a large dollop of additional API churn on top of this, and it would only help 32-bit platforms which seem relatively less likely to see any benefit. Andreas Scherbaum, reviewed by Christian Ullrich, additional hacking by me
2016-03-12 22:05:10 +01:00
static HV *plperl_spi_execute_fetch_result(SPITupleTable *, uint64, int);
PL/Perl portability fix: avoid including XSUB.h in plperl.c. In Perl builds that define PERL_IMPLICIT_SYS, XSUB.h defines macros that replace a whole lot of basic libc functions with Perl functions. We can't tolerate that in plperl.c; it breaks at least PG_TRY and probably other stuff. The core idea of this patch is to include XSUB.h only in the .xs files where it's really needed, and to move any code broken by PERL_IMPLICIT_SYS out of the .xs files and into plperl.c. The reason this hasn't been a problem before is that our build techniques did not result in PERL_IMPLICIT_SYS appearing as a #define in PL/Perl, even on some platforms where Perl thinks it is defined. That's about to change in order to fix a nasty portability issue, so we need this work to make the code safe for that. Rather unaccountably, the Perl people chose XSUB.h as the place to provide the versions of the aTHX/aTHX_ macros that are needed by code that's not explicitly aware of the MULTIPLICITY API conventions. Hence, just removing XSUB.h from plperl.c fails miserably. But we can work around that by defining PERL_NO_GET_CONTEXT (which would make the relevant stanza of XSUB.h a no-op anyway). As explained in perlguts.pod, that means we need to add a "dTHX" macro call in every C function that calls a Perl API function. In most of them we just add this at the top; but since the macro fetches the current Perl interpreter pointer, more care is needed in functions that switch the active interpreter. Lack of the macro is easily recognized since it results in bleats about "my_perl" not being defined. (A nice side benefit of this is that it significantly reduces the number of fetches of the current interpreter pointer. On my machine, plperl.so gets more than 10% smaller, and there's probably some performance win too. We could reduce the number of fetches still more by decorating the code with pTHX_/aTHX_ macros to pass the interpreter pointer around, as explained by perlguts.pod; but that's a task for another day.) Formatting note: pgindent seems happy to treat "dTHX;" as a declaration so long as it's the first thing after the left brace, as we'd already observed with respect to the similar macro "dSP;". If you try to put it later in a set of declarations, pgindent puts ugly extra space around it. Having removed XSUB.h from plperl.c, we need only move the support functions for spi_return_next and util_elog (both of which use PG_TRY) out of the .xs files and into plperl.c. This seems sufficient to avoid the known problems caused by PERL_IMPLICIT_SYS, although we could move more code if additional issues emerge. This will need to be back-patched, but first let's see what the buildfarm makes of it. Patch by me, with some help from Ashutosh Sharma Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
2017-07-28 18:25:43 +02:00
static void plperl_return_next_internal(SV *sv);
Force strings passed to and from plperl to be in UTF8 encoding. String are converted to UTF8 on the way into perl and to the database encoding on the way back. This avoids a number of observed anomalies, and ensures Perl a consistent view of the world. Some minor code cleanups are also accomplished. Alex Hunsaker, reviewed by Andy Colson.
2011-02-06 23:29:26 +01:00
static char *hek2cstr(HE *he);
Adjust plperl to ensure that all strings and hash keys passed to Perl are marked as UTF8 when the database encoding is UTF8. This should avoid inconsistencies like that exhibited in bug #2683 from Vitali Stupin.
2006-10-15 20:56:39 +02:00
static SV **hv_store_string(HV *hv, const char *key, SV *val);
static SV **hv_fetch_string(HV *hv, const char *key);
Add some const decorations to prototypes Reviewed-by: Fabien COELHO <coelho@cri.ensmp.fr>
2017-10-31 15:34:31 +01:00
static void plperl_create_sub(plperl_proc_desc *desc, const char *s, Oid fn_oid);
pgindent run on plperl.c
2011-02-17 20:40:13 +01:00
static SV *plperl_call_perl_func(plperl_proc_desc *desc,
FunctionCallInfo fcinfo);
errcontext support in PL/Perl Author: Alexey Klyukin <alexk@commandprompt.com>
2009-09-16 08:06:12 +02:00
static void plperl_compile_callback(void *arg);
static void plperl_exec_callback(void *arg);
Add support for anonymous code blocks (DO blocks) to PL/Perl. Joshua Tolley, reviewed by Brendan Jurd and Tim Bunce
2009-11-29 04:02:27 +01:00
static void plperl_inline_callback(void *arg);
Various small improvements and cleanups for PL/Perl. - Allow (ineffective) use of 'require' in plperl If the required module is not already loaded then it dies. So "use strict;" now works in plperl. - Pre-load the feature module if perl >= 5.10. So "use feature :5.10;" now works in plperl. - Stored procedure subs are now given names. The names are not visible in ordinary use, but they make tools like Devel::NYTProf and Devel::Cover much more useful. - Simplified and generalized the subroutine creation code. Now one code path for generating sub source code, not four. Can generate multiple 'use' statements with specific imports (which handles plperl.use_strict currently and can easily be extended to handle a plperl.use_feature=':5.12' in future). - Disallows use of Safe version 2.20 which is broken for PL/Perl. http://rt.perl.org/rt3/Ticket/Display.html?id=72068 - Assorted minor optimizations by pre-growing data structures. Patch from Tim Bunce, reviewed by Alex Hunsaker.
2010-01-27 00:11:56 +01:00
static char *strip_trailing_ws(const char *msg);
static OP *pp_require_safe(pTHX);
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
static void activate_interpreter(plperl_interp_desc *interp_desc);
pgindent run for 9.0, second run
2010-07-06 21:19:02 +02:00
plperl: windows: Use Perl_setlocale on 5.28+, fixing compile failure. For older versions we need our own copy of perl's setlocale(), because it was not exposed (why we need the setlocale in the first place is explained in plperl_init_interp) . The copy stopped working in 5.28, as some of the used macros are not public anymore. But Perl_setlocale is available in 5.28, so use that. Author: Victor Wagner <vitus@wagner.pp.ru> Reviewed-By: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Discussion: https://postgr.es/m/20200501134711.08750c5f@antares.wagner.home Backpatch: all versions
2022-01-30 23:29:04 +01:00
#if defined(WIN32) && PERL_VERSION_LT(5, 28, 0)
Abandon the use of Perl's Safe.pm to enforce restrictions in plperl, as it is fundamentally insecure. Instead apply an opmask to the whole interpreter that imposes restrictions on unsafe operations. These restrictions are much harder to subvert than is Safe.pm, since there is no container to be broken out of. Backported to release 7.4. In releases 7.4, 8.0 and 8.1 this also includes the necessary backporting of the two interpreters model for plperl and plperlu adopted in release 8.2. In versions 8.0 and up, the use of Perl's POSIX module to undo its locale mangling on Windows has become insecure with these changes, so it is replaced by our own routine, which is also faster. Nice side effects of the changes include that it is now possible to use perl's "strict" pragma in a natural way in plperl, and that perl's $a and $b variables now work as expected in sort routines, and that function compilation is significantly faster. Tim Bunce and Andrew Dunstan, with reviews from Alex Hunsaker and Alexey Klyukin. Security: CVE-2010-1169
2010-05-13 18:39:43 +02:00
static char *setlocale_perl(int category, char *locale);
plperl: windows: Use Perl_setlocale on 5.28+, fixing compile failure. For older versions we need our own copy of perl's setlocale(), because it was not exposed (why we need the setlocale in the first place is explained in plperl_init_interp) . The copy stopped working in 5.28, as some of the used macros are not public anymore. But Perl_setlocale is available in 5.28, so use that. Author: Victor Wagner <vitus@wagner.pp.ru> Reviewed-By: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Discussion: https://postgr.es/m/20200501134711.08750c5f@antares.wagner.home Backpatch: all versions
2022-01-30 23:29:04 +01:00
#else
#define setlocale_perl(a,b) Perl_setlocale(a,b)
#endif /* defined(WIN32) && PERL_VERSION_LT(5, 28, 0) */
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
PL/Perl portability fix: avoid including XSUB.h in plperl.c. In Perl builds that define PERL_IMPLICIT_SYS, XSUB.h defines macros that replace a whole lot of basic libc functions with Perl functions. We can't tolerate that in plperl.c; it breaks at least PG_TRY and probably other stuff. The core idea of this patch is to include XSUB.h only in the .xs files where it's really needed, and to move any code broken by PERL_IMPLICIT_SYS out of the .xs files and into plperl.c. The reason this hasn't been a problem before is that our build techniques did not result in PERL_IMPLICIT_SYS appearing as a #define in PL/Perl, even on some platforms where Perl thinks it is defined. That's about to change in order to fix a nasty portability issue, so we need this work to make the code safe for that. Rather unaccountably, the Perl people chose XSUB.h as the place to provide the versions of the aTHX/aTHX_ macros that are needed by code that's not explicitly aware of the MULTIPLICITY API conventions. Hence, just removing XSUB.h from plperl.c fails miserably. But we can work around that by defining PERL_NO_GET_CONTEXT (which would make the relevant stanza of XSUB.h a no-op anyway). As explained in perlguts.pod, that means we need to add a "dTHX" macro call in every C function that calls a Perl API function. In most of them we just add this at the top; but since the macro fetches the current Perl interpreter pointer, more care is needed in functions that switch the active interpreter. Lack of the macro is easily recognized since it results in bleats about "my_perl" not being defined. (A nice side benefit of this is that it significantly reduces the number of fetches of the current interpreter pointer. On my machine, plperl.so gets more than 10% smaller, and there's probably some performance win too. We could reduce the number of fetches still more by decorating the code with pTHX_/aTHX_ macros to pass the interpreter pointer around, as explained by perlguts.pod; but that's a task for another day.) Formatting note: pgindent seems happy to treat "dTHX;" as a declaration so long as it's the first thing after the left brace, as we'd already observed with respect to the similar macro "dSP;". If you try to put it later in a set of declarations, pgindent puts ugly extra space around it. Having removed XSUB.h from plperl.c, we need only move the support functions for spi_return_next and util_elog (both of which use PG_TRY) out of the .xs files and into plperl.c. This seems sufficient to avoid the known problems caused by PERL_IMPLICIT_SYS, although we could move more code if additional issues emerge. This will need to be back-patched, but first let's see what the buildfarm makes of it. Patch by me, with some help from Ashutosh Sharma Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
2017-07-28 18:25:43 +02:00
/*
* Decrement the refcount of the given SV within the active Perl interpreter
*
* This is handy because it reloads the active-interpreter pointer, saving
* some notation in callers that switch the active interpreter.
*/
static inline void
SvREFCNT_dec_current(SV *sv)
{
dTHX;
SvREFCNT_dec(sv);
}
Tidy up and refactor plperl.c. - Changed MULTIPLICITY check from runtime to compiletime. No loads the large Config module. - Changed plperl_init_interp() to return new interp and not alter the global interp_state - Moved plperl_safe_init() call into check_interp(). - Removed plperl_safe_init_done state variable as interp_state now covers that role. - Changed plperl_create_sub() to take a plperl_proc_desc argument. - Simplified return value handling in plperl_create_sub. - Changed perl.com link in the docs to perl.org and tweaked wording to clarify that require, not use, is what's blocked. - Moved perl code in large multi-line C string literal macros out to plc_*.pl files. - Added a test2macro.pl utility to convert the plc_*.pl files to macros in a perlchunks.h file which is #included - Simplifed plperl_safe_init() slightly - Optimized pg_verifymbstr calls to avoid unneeded strlen()s. Patch from Tim Bunce, with minor editing from me.
2010-01-09 03:40:50 +01:00
/*
Force strings passed to and from plperl to be in UTF8 encoding. String are converted to UTF8 on the way into perl and to the database encoding on the way back. This avoids a number of observed anomalies, and ensures Perl a consistent view of the world. Some minor code cleanups are also accomplished. Alex Hunsaker, reviewed by Andy Colson.
2011-02-06 23:29:26 +01:00
* convert a HE (hash entry) key to a cstr in the current database encoding
Tidy up and refactor plperl.c. - Changed MULTIPLICITY check from runtime to compiletime. No loads the large Config module. - Changed plperl_init_interp() to return new interp and not alter the global interp_state - Moved plperl_safe_init() call into check_interp(). - Removed plperl_safe_init_done state variable as interp_state now covers that role. - Changed plperl_create_sub() to take a plperl_proc_desc argument. - Simplified return value handling in plperl_create_sub. - Changed perl.com link in the docs to perl.org and tweaked wording to clarify that require, not use, is what's blocked. - Moved perl code in large multi-line C string literal macros out to plc_*.pl files. - Added a test2macro.pl utility to convert the plc_*.pl files to macros in a perlchunks.h file which is #included - Simplifed plperl_safe_init() slightly - Optimized pg_verifymbstr calls to avoid unneeded strlen()s. Patch from Tim Bunce, with minor editing from me.
2010-01-09 03:40:50 +01:00
*/
Force strings passed to and from plperl to be in UTF8 encoding. String are converted to UTF8 on the way into perl and to the database encoding on the way back. This avoids a number of observed anomalies, and ensures Perl a consistent view of the world. Some minor code cleanups are also accomplished. Alex Hunsaker, reviewed by Andy Colson.
2011-02-06 23:29:26 +01:00
static char *
hek2cstr(HE *he)
Tidy up and refactor plperl.c. - Changed MULTIPLICITY check from runtime to compiletime. No loads the large Config module. - Changed plperl_init_interp() to return new interp and not alter the global interp_state - Moved plperl_safe_init() call into check_interp(). - Removed plperl_safe_init_done state variable as interp_state now covers that role. - Changed plperl_create_sub() to take a plperl_proc_desc argument. - Simplified return value handling in plperl_create_sub. - Changed perl.com link in the docs to perl.org and tweaked wording to clarify that require, not use, is what's blocked. - Moved perl code in large multi-line C string literal macros out to plc_*.pl files. - Added a test2macro.pl utility to convert the plc_*.pl files to macros in a perlchunks.h file which is #included - Simplifed plperl_safe_init() slightly - Optimized pg_verifymbstr calls to avoid unneeded strlen()s. Patch from Tim Bunce, with minor editing from me.
2010-01-09 03:40:50 +01:00
{
PL/Perl portability fix: avoid including XSUB.h in plperl.c. In Perl builds that define PERL_IMPLICIT_SYS, XSUB.h defines macros that replace a whole lot of basic libc functions with Perl functions. We can't tolerate that in plperl.c; it breaks at least PG_TRY and probably other stuff. The core idea of this patch is to include XSUB.h only in the .xs files where it's really needed, and to move any code broken by PERL_IMPLICIT_SYS out of the .xs files and into plperl.c. The reason this hasn't been a problem before is that our build techniques did not result in PERL_IMPLICIT_SYS appearing as a #define in PL/Perl, even on some platforms where Perl thinks it is defined. That's about to change in order to fix a nasty portability issue, so we need this work to make the code safe for that. Rather unaccountably, the Perl people chose XSUB.h as the place to provide the versions of the aTHX/aTHX_ macros that are needed by code that's not explicitly aware of the MULTIPLICITY API conventions. Hence, just removing XSUB.h from plperl.c fails miserably. But we can work around that by defining PERL_NO_GET_CONTEXT (which would make the relevant stanza of XSUB.h a no-op anyway). As explained in perlguts.pod, that means we need to add a "dTHX" macro call in every C function that calls a Perl API function. In most of them we just add this at the top; but since the macro fetches the current Perl interpreter pointer, more care is needed in functions that switch the active interpreter. Lack of the macro is easily recognized since it results in bleats about "my_perl" not being defined. (A nice side benefit of this is that it significantly reduces the number of fetches of the current interpreter pointer. On my machine, plperl.so gets more than 10% smaller, and there's probably some performance win too. We could reduce the number of fetches still more by decorating the code with pTHX_/aTHX_ macros to pass the interpreter pointer around, as explained by perlguts.pod; but that's a task for another day.) Formatting note: pgindent seems happy to treat "dTHX;" as a declaration so long as it's the first thing after the left brace, as we'd already observed with respect to the similar macro "dSP;". If you try to put it later in a set of declarations, pgindent puts ugly extra space around it. Having removed XSUB.h from plperl.c, we need only move the support functions for spi_return_next and util_elog (both of which use PG_TRY) out of the .xs files and into plperl.c. This seems sufficient to avoid the known problems caused by PERL_IMPLICIT_SYS, although we could move more code if additional issues emerge. This will need to be back-patched, but first let's see what the buildfarm makes of it. Patch by me, with some help from Ashutosh Sharma Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
2017-07-28 18:25:43 +02:00
dTHX;
plperl: Fix memory leak in hek2cstr Backpatch all the way back to 9.1, where it was introduced by commit 50d89d42. Reported by Sergey Burladyan in #9223 Author: Alex Hunsaker
2014-03-17 03:22:21 +01:00
char *ret;
SV *sv;
/*
* HeSVKEY_force will return a temporary mortal SV*, so we need to make
* sure to free it with ENTER/SAVE/FREE/LEAVE
*/
ENTER;
SAVETMPS;
pgindent run on plperl.c
2011-02-17 20:40:13 +01:00
/*-------------------------
Fix various typos, grammar and code style in comments and docs This fixes a set of issues that have accumulated over the past months (or years) in various code areas. Most fixes are related to some recent additions, as of the development of v15. Author: Justin Pryzby Discussion: https://postgr.es/m/20220124030001.GQ23027@telsasoft.com
2022-01-25 01:40:04 +01:00
* Unfortunately, while HeUTF8 is true for most things > 256, for values
pgindent run on plperl.c
2011-02-17 20:40:13 +01:00
* 128..255 it's not, but perl will treat them as unicode code points if
* the utf8 flag is not set ( see The "Unicode Bug" in perldoc perlunicode
* for more)
Force strings passed to and from plperl to be in UTF8 encoding. String are converted to UTF8 on the way into perl and to the database encoding on the way back. This avoids a number of observed anomalies, and ensures Perl a consistent view of the world. Some minor code cleanups are also accomplished. Alex Hunsaker, reviewed by Andy Colson.
2011-02-06 23:29:26 +01:00
*
* So if we did the expected:
pgindent run on plperl.c
2011-02-17 20:40:13 +01:00
* if (HeUTF8(he))
* utf_u2e(key...);
* else // must be ascii
* return HePV(he);
Force strings passed to and from plperl to be in UTF8 encoding. String are converted to UTF8 on the way into perl and to the database encoding on the way back. This avoids a number of observed anomalies, and ensures Perl a consistent view of the world. Some minor code cleanups are also accomplished. Alex Hunsaker, reviewed by Andy Colson.
2011-02-06 23:29:26 +01:00
* we won't match columns with codepoints from 128..255
*
pgindent run on plperl.c
2011-02-17 20:40:13 +01:00
* For a more concrete example given a column with the name of the unicode
* codepoint U+00ae (registered sign) and a UTF8 database and the perl
* return_next { "\N{U+00ae}=>'text } would always fail as heUTF8 returns
* 0 and HePV() would give us a char * with 1 byte contains the decimal
* value 174
Force strings passed to and from plperl to be in UTF8 encoding. String are converted to UTF8 on the way into perl and to the database encoding on the way back. This avoids a number of observed anomalies, and ensures Perl a consistent view of the world. Some minor code cleanups are also accomplished. Alex Hunsaker, reviewed by Andy Colson.
2011-02-06 23:29:26 +01:00
*
pgindent run on plperl.c
2011-02-17 20:40:13 +01:00
* Perl has the brains to know when it should utf8 encode 174 properly, so
* here we force it into an SV so that perl will figure it out and do the
* right thing
*-------------------------
Tidy up and refactor plperl.c. - Changed MULTIPLICITY check from runtime to compiletime. No loads the large Config module. - Changed plperl_init_interp() to return new interp and not alter the global interp_state - Moved plperl_safe_init() call into check_interp(). - Removed plperl_safe_init_done state variable as interp_state now covers that role. - Changed plperl_create_sub() to take a plperl_proc_desc argument. - Simplified return value handling in plperl_create_sub. - Changed perl.com link in the docs to perl.org and tweaked wording to clarify that require, not use, is what's blocked. - Moved perl code in large multi-line C string literal macros out to plc_*.pl files. - Added a test2macro.pl utility to convert the plc_*.pl files to macros in a perlchunks.h file which is #included - Simplifed plperl_safe_init() slightly - Optimized pg_verifymbstr calls to avoid unneeded strlen()s. Patch from Tim Bunce, with minor editing from me.
2010-01-09 03:40:50 +01:00
*/
pgindent run on plperl.c
2011-02-17 20:40:13 +01:00
plperl: Fix memory leak in hek2cstr Backpatch all the way back to 9.1, where it was introduced by commit 50d89d42. Reported by Sergey Burladyan in #9223 Author: Alex Hunsaker
2014-03-17 03:22:21 +01:00
sv = HeSVKEY_force(he);
Force strings passed to and from plperl to be in UTF8 encoding. String are converted to UTF8 on the way into perl and to the database encoding on the way back. This avoids a number of observed anomalies, and ensures Perl a consistent view of the world. Some minor code cleanups are also accomplished. Alex Hunsaker, reviewed by Andy Colson.
2011-02-06 23:29:26 +01:00
if (HeUTF8(he))
SvUTF8_on(sv);
plperl: Fix memory leak in hek2cstr Backpatch all the way back to 9.1, where it was introduced by commit 50d89d42. Reported by Sergey Burladyan in #9223 Author: Alex Hunsaker
2014-03-17 03:22:21 +01:00
ret = sv2cstr(sv);
/* free sv */
FREETMPS;
LEAVE;
return ret;
Tidy up and refactor plperl.c. - Changed MULTIPLICITY check from runtime to compiletime. No loads the large Config module. - Changed plperl_init_interp() to return new interp and not alter the global interp_state - Moved plperl_safe_init() call into check_interp(). - Removed plperl_safe_init_done state variable as interp_state now covers that role. - Changed plperl_create_sub() to take a plperl_proc_desc argument. - Simplified return value handling in plperl_create_sub. - Changed perl.com link in the docs to perl.org and tweaked wording to clarify that require, not use, is what's blocked. - Moved perl code in large multi-line C string literal macros out to plc_*.pl files. - Added a test2macro.pl utility to convert the plc_*.pl files to macros in a perlchunks.h file which is #included - Simplifed plperl_safe_init() slightly - Optimized pg_verifymbstr calls to avoid unneeded strlen()s. Patch from Tim Bunce, with minor editing from me.
2010-01-09 03:40:50 +01:00
}
At 2005-05-21 20:18:50 +0530, ams@oryx.com wrote: > > > The second issue is where plperl returns a large result set. I have attached the following seven patches to address this problem: 1. Trivial. Replaces some errant spaces with tabs. 2. Trivial. Fixes the spelling of Jan's name, and gets rid of many inane, useless, annoying, and often misleading comments. Here's a sample: "plperl_init_all() - Initialize all". (I have tried to add some useful comments here and there, and will continue to do so now and again.) 3. Trivial. Splits up some long lines. 4. Converts SRFs in PL/Perl to use a Tuplestore and SFRM_Materialize to return the result set, based on the PL/PgSQL model. There are two major consequences: result sets will spill to disk when they can no longer fit in work_mem; and "select foo_srf()" no longer works. (I didn't lose sleep over the latter, since that form is not valid in PL/PgSQL, and it's not documented in PL/Perl.) 5. Trivial, but important. Fixes use of "undef" instead of undef. This would cause empty functions to fail in bizarre ways. I suspect that there's still another (old) bug here. I'll investigate further. 6. Moves the majority of (4) out into a new plperl_return_next() function, to make it possible to expose the functionality to Perl; cleans up some of the code besides. 7. Add an spi_return_next function for use in Perl code. If you want to apply the patches and try them out, 8-composite.diff is what you should use. (Note: my patches depend upon Andrew's use-strict and %_SHARED patches being applied.) Here's something to try: create or replace function foo() returns setof record as $$ $i = 0; for ("World", "PostgreSQL", "PL/Perl") { spi_return_next({f1=>++$i, f2=>'Hello', f3=>$_}); } return; $$ language plperl; select * from foo() as (f1 integer, f2 text, f3 text); (Many thanks to Andrews Dunstan and Supernews for their help.) Abhijit Menon-Sen
2005-06-04 22:33:06 +02:00
Add a feature for automatic initialization and finalization of dynamically loaded libraries: call functions _PG_init() and _PG_fini() if the library defines such symbols. Hence we no longer need to specify an initialization function in preload_libraries: we can assume that the library used the _PG_init() convention, instead. This removes one source of pilot error in use of preloaded libraries. Original patch by Ralf Engelschall, preload_libraries changes by me.
2006-08-08 21:15:09 +02:00
/*
* _PG_init() - library load-time initialization
*
* DO NOT make this static nor change its name!
*/
Cause library-preload feature to report error if specified initialization function is not found. Also, make all the PL libraries have initialization functions with standard names. Patch from Joe Conway.
2003-07-31 20:36:46 +02:00
void
Add a feature for automatic initialization and finalization of dynamically loaded libraries: call functions _PG_init() and _PG_fini() if the library defines such symbols. Hence we no longer need to specify an initialization function in preload_libraries: we can assume that the library used the _PG_init() convention, instead. This removes one source of pilot error in use of preloaded libraries. Original patch by Ralf Engelschall, preload_libraries changes by me.
2006-08-08 21:15:09 +02:00
_PG_init(void)
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
{
Abandon the use of Perl's Safe.pm to enforce restrictions in plperl, as it is fundamentally insecure. Instead apply an opmask to the whole interpreter that imposes restrictions on unsafe operations. These restrictions are much harder to subvert than is Safe.pm, since there is no container to be broken out of. Backported to release 7.4. In releases 7.4, 8.0 and 8.1 this also includes the necessary backporting of the two interpreters model for plperl and plperlu adopted in release 8.2. In versions 8.0 and up, the use of Perl's POSIX module to undo its locale mangling on Windows has become insecure with these changes, so it is replaced by our own routine, which is also faster. Nice side effects of the changes include that it is now possible to use perl's "strict" pragma in a natural way in plperl, and that perl's $a and $b variables now work as expected in sort routines, and that function compilation is significantly faster. Tim Bunce and Andrew Dunstan, with reviews from Alex Hunsaker and Alexey Klyukin. Security: CVE-2010-1169
2010-05-13 18:39:43 +02:00
/*
* Be sure we do initialization only once.
*
* If initialization fails due to, e.g., plperl_init_interp() throwing an
* exception, then we'll return here on the next usage and the user will
* get a rather cryptic: ERROR: attempt to redefine parameter
* "plperl.use_strict"
*/
Add a feature for automatic initialization and finalization of dynamically loaded libraries: call functions _PG_init() and _PG_fini() if the library defines such symbols. Hence we no longer need to specify an initialization function in preload_libraries: we can assume that the library used the _PG_init() convention, instead. This removes one source of pilot error in use of preloaded libraries. Original patch by Ralf Engelschall, preload_libraries changes by me.
2006-08-08 21:15:09 +02:00
static bool inited = false;
Force plperl and plperlu to run in separate interpreters. Create an error on an attempt to create the second interpreter if this is not supported by the perl installation. Per recent -hackers discussion.
2006-11-13 18:13:57 +01:00
HASHCTL hash_ctl;
Add a feature for automatic initialization and finalization of dynamically loaded libraries: call functions _PG_init() and _PG_fini() if the library defines such symbols. Hence we no longer need to specify an initialization function in preload_libraries: we can assume that the library used the _PG_init() convention, instead. This removes one source of pilot error in use of preloaded libraries. Original patch by Ralf Engelschall, preload_libraries changes by me.
2006-08-08 21:15:09 +02:00
if (inited)
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
return;
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
/*
* Support localized messages.
*/
Append major version number and for libraries soname major version number to the gettext domain name, to simplify parallel installations. Also, rename set_text_domain() to pg_bindtextdomain(), because that is what it does.
2008-12-11 08:34:09 +01:00
pg_bindtextdomain(TEXTDOMAIN);
Improve translatability of error messages for external modules by tweaking the ereport macro. Included in this commit are enough files for starting plpgsql, plpython, plperl and pltcl translations.
2008-10-09 19:24:05 +02:00
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
/*
* Initialize plperl's GUCs.
*/
Add a feature for automatic initialization and finalization of dynamically loaded libraries: call functions _PG_init() and _PG_fini() if the library defines such symbols. Hence we no longer need to specify an initialization function in preload_libraries: we can assume that the library used the _PG_init() convention, instead. This removes one source of pilot error in use of preloaded libraries. Original patch by Ralf Engelschall, preload_libraries changes by me.
2006-08-08 21:15:09 +02:00
DefineCustomBoolVariable("plperl.use_strict",
Wordsmithing for PL/Perl messages
2009-02-19 11:33:17 +01:00
gettext_noop("If true, trusted and untrusted Perl code will be compiled in strict mode."),
At 2005-05-21 20:18:50 +0530, ams@oryx.com wrote: > > > The second issue is where plperl returns a large result set. I have attached the following seven patches to address this problem: 1. Trivial. Replaces some errant spaces with tabs. 2. Trivial. Fixes the spelling of Jan's name, and gets rid of many inane, useless, annoying, and often misleading comments. Here's a sample: "plperl_init_all() - Initialize all". (I have tried to add some useful comments here and there, and will continue to do so now and again.) 3. Trivial. Splits up some long lines. 4. Converts SRFs in PL/Perl to use a Tuplestore and SFRM_Materialize to return the result set, based on the PL/PgSQL model. There are two major consequences: result sets will spill to disk when they can no longer fit in work_mem; and "select foo_srf()" no longer works. (I didn't lose sleep over the latter, since that form is not valid in PL/PgSQL, and it's not documented in PL/Perl.) 5. Trivial, but important. Fixes use of "undef" instead of undef. This would cause empty functions to fail in bizarre ways. I suspect that there's still another (old) bug here. I'll investigate further. 6. Moves the majority of (4) out into a new plperl_return_next() function, to make it possible to expose the functionality to Perl; cleans up some of the code besides. 7. Add an spi_return_next function for use in Perl code. If you want to apply the patches and try them out, 8-composite.diff is what you should use. (Note: my patches depend upon Andrew's use-strict and %_SHARED patches being applied.) Here's something to try: create or replace function foo() returns setof record as $$ $i = 0; for ("World", "PostgreSQL", "PL/Perl") { spi_return_next({f1=>++$i, f2=>'Hello', f3=>$_}); } return; $$ language plperl; select * from foo() as (f1 integer, f2 text, f3 text); (Many thanks to Andrews Dunstan and Supernews for their help.) Abhijit Menon-Sen
2005-06-04 22:33:06 +02:00
NULL,
&plperl_use_strict,
Some infrastructure changes for the upcoming auto-explain contrib module: * Refactor explain.c slightly to export a convenient-to-use subroutine for printing EXPLAIN results. * Provide hooks for plugins to get control at ExecutorStart and ExecutorEnd as well as ExecutorRun. * Add some minimal support for tracking the total runtime of ExecutorRun. This code won't actually do anything unless a plugin prods it to. * Change the API of the DefineCustomXXXVariable functions to allow nonzero "flags" to be specified for a custom GUC variable. While at it, also make the "bootstrap" default value for custom GUCs be explicitly specified as a parameter to these functions. This is to eliminate confusion over where the default comes from, as has been expressed in the past by some users of the custom-variable facility. * Refactor GUC code a bit to ensure that a custom variable gets initialized to something valid (like its default value) even if the placeholder value was invalid.
2008-11-19 02:10:24 +01:00
false,
PGC_USERSET, 0,
Revise the API for GUC variable assign hooks. The previous functions of assign hooks are now split between check hooks and assign hooks, where the former can fail but the latter shouldn't. Aside from being conceptually clearer, this approach exposes the "canonicalized" form of the variable value to guc.c without having to do an actual assignment. And that lets us fix the problem recently noted by Bernd Helmle that the auto-tune patch for wal_buffers resulted in bogus log messages about "parameter "wal_buffers" cannot be changed without restarting the server". There may be some speed advantage too, because this design lets hook functions avoid re-parsing variable values when restoring a previous state after a rollback (they can store a pre-parsed representation of the value instead). This patch also resolves a longstanding annoyance about custom error messages from variable assign hooks: they should modify, not appear separately from, guc.c's own message about "invalid parameter value".
2011-04-07 06:11:01 +02:00
NULL, NULL, NULL);
At 2005-05-21 20:18:50 +0530, ams@oryx.com wrote: > > > The second issue is where plperl returns a large result set. I have attached the following seven patches to address this problem: 1. Trivial. Replaces some errant spaces with tabs. 2. Trivial. Fixes the spelling of Jan's name, and gets rid of many inane, useless, annoying, and often misleading comments. Here's a sample: "plperl_init_all() - Initialize all". (I have tried to add some useful comments here and there, and will continue to do so now and again.) 3. Trivial. Splits up some long lines. 4. Converts SRFs in PL/Perl to use a Tuplestore and SFRM_Materialize to return the result set, based on the PL/PgSQL model. There are two major consequences: result sets will spill to disk when they can no longer fit in work_mem; and "select foo_srf()" no longer works. (I didn't lose sleep over the latter, since that form is not valid in PL/PgSQL, and it's not documented in PL/Perl.) 5. Trivial, but important. Fixes use of "undef" instead of undef. This would cause empty functions to fail in bizarre ways. I suspect that there's still another (old) bug here. I'll investigate further. 6. Moves the majority of (4) out into a new plperl_return_next() function, to make it possible to expose the functionality to Perl; cleans up some of the code besides. 7. Add an spi_return_next function for use in Perl code. If you want to apply the patches and try them out, 8-composite.diff is what you should use. (Note: my patches depend upon Andrew's use-strict and %_SHARED patches being applied.) Here's something to try: create or replace function foo() returns setof record as $$ $i = 0; for ("World", "PostgreSQL", "PL/Perl") { spi_return_next({f1=>++$i, f2=>'Hello', f3=>$_}); } return; $$ language plperl; select * from foo() as (f1 integer, f2 text, f3 text); (Many thanks to Andrews Dunstan and Supernews for their help.) Abhijit Menon-Sen
2005-06-04 22:33:06 +02:00
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
/*
* plperl.on_init is marked PGC_SIGHUP to support the idea that it might
* be executed in the postmaster (if plperl is loaded into the postmaster
* via shared_preload_libraries). This isn't really right either way,
* though.
*/
Add plperl.on_plperl_init and plperl.on_plperlu_init settings for language-specific startup. Rename recently added plperl.on_perl_init to plperl.on_init. Also, code cleanup for utf8 hack. Patch from Tim Bunce, reviewed by Alex Hunsaker.
2010-02-12 20:35:25 +01:00
DefineCustomStringVariable("plperl.on_init",
Message style tuning
2010-03-17 22:31:17 +01:00
gettext_noop("Perl initialization code to execute when a Perl interpreter is initialized."),
Add plperl.on_perl_init setting to provide for initializing the perl library on load. Also, handle END blocks in plperl. Database access is disallowed during both these operations, although it might be allowed in END blocks in future. Patch from Tim Bunce.
2010-01-30 02:46:57 +01:00
NULL,
Add plperl.on_plperl_init and plperl.on_plperlu_init settings for language-specific startup. Rename recently added plperl.on_perl_init to plperl.on_init. Also, code cleanup for utf8 hack. Patch from Tim Bunce, reviewed by Alex Hunsaker.
2010-02-12 20:35:25 +01:00
&plperl_on_init,
Add plperl.on_perl_init setting to provide for initializing the perl library on load. Also, handle END blocks in plperl. Database access is disallowed during both these operations, although it might be allowed in END blocks in future. Patch from Tim Bunce.
2010-01-30 02:46:57 +01:00
NULL,
PGC_SIGHUP, 0,
Revise the API for GUC variable assign hooks. The previous functions of assign hooks are now split between check hooks and assign hooks, where the former can fail but the latter shouldn't. Aside from being conceptually clearer, this approach exposes the "canonicalized" form of the variable value to guc.c without having to do an actual assignment. And that lets us fix the problem recently noted by Bernd Helmle that the auto-tune patch for wal_buffers resulted in bogus log messages about "parameter "wal_buffers" cannot be changed without restarting the server". There may be some speed advantage too, because this design lets hook functions avoid re-parsing variable values when restoring a previous state after a rollback (they can store a pre-parsed representation of the value instead). This patch also resolves a longstanding annoyance about custom error messages from variable assign hooks: they should modify, not appear separately from, guc.c's own message about "invalid parameter value".
2011-04-07 06:11:01 +02:00
NULL, NULL, NULL);
Add plperl.on_perl_init setting to provide for initializing the perl library on load. Also, handle END blocks in plperl. Database access is disallowed during both these operations, although it might be allowed in END blocks in future. Patch from Tim Bunce.
2010-01-30 02:46:57 +01:00
Add plperl.on_plperl_init and plperl.on_plperlu_init settings for language-specific startup. Rename recently added plperl.on_perl_init to plperl.on_init. Also, code cleanup for utf8 hack. Patch from Tim Bunce, reviewed by Alex Hunsaker.
2010-02-12 20:35:25 +01:00
/*
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
* plperl.on_plperl_init is marked PGC_SUSET to avoid issues whereby a
* user who might not even have USAGE privilege on the plperl language
* could nonetheless use SET plperl.on_plperl_init='...' to influence the
* behaviour of any existing plperl function that they can execute (which
* might be SECURITY DEFINER, leading to a privilege escalation). See
Add plperl.on_plperl_init and plperl.on_plperlu_init settings for language-specific startup. Rename recently added plperl.on_perl_init to plperl.on_init. Also, code cleanup for utf8 hack. Patch from Tim Bunce, reviewed by Alex Hunsaker.
2010-02-12 20:35:25 +01:00
* http://archives.postgresql.org/pgsql-hackers/2010-02/msg00281.php and
* the overall thread.
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
*
* Note that because plperl.use_strict is USERSET, a nefarious user could
* set it to be applied against other people's functions. This is judged
* OK since the worst result would be an error. Your code oughta pass
* use_strict anyway ;-)
Add plperl.on_plperl_init and plperl.on_plperlu_init settings for language-specific startup. Rename recently added plperl.on_perl_init to plperl.on_init. Also, code cleanup for utf8 hack. Patch from Tim Bunce, reviewed by Alex Hunsaker.
2010-02-12 20:35:25 +01:00
*/
DefineCustomStringVariable("plperl.on_plperl_init",
gettext_noop("Perl initialization code to execute once when plperl is first used."),
NULL,
&plperl_on_plperl_init,
NULL,
PGC_SUSET, 0,
Revise the API for GUC variable assign hooks. The previous functions of assign hooks are now split between check hooks and assign hooks, where the former can fail but the latter shouldn't. Aside from being conceptually clearer, this approach exposes the "canonicalized" form of the variable value to guc.c without having to do an actual assignment. And that lets us fix the problem recently noted by Bernd Helmle that the auto-tune patch for wal_buffers resulted in bogus log messages about "parameter "wal_buffers" cannot be changed without restarting the server". There may be some speed advantage too, because this design lets hook functions avoid re-parsing variable values when restoring a previous state after a rollback (they can store a pre-parsed representation of the value instead). This patch also resolves a longstanding annoyance about custom error messages from variable assign hooks: they should modify, not appear separately from, guc.c's own message about "invalid parameter value".
2011-04-07 06:11:01 +02:00
NULL, NULL, NULL);
Add plperl.on_plperl_init and plperl.on_plperlu_init settings for language-specific startup. Rename recently added plperl.on_perl_init to plperl.on_init. Also, code cleanup for utf8 hack. Patch from Tim Bunce, reviewed by Alex Hunsaker.
2010-02-12 20:35:25 +01:00
DefineCustomStringVariable("plperl.on_plperlu_init",
gettext_noop("Perl initialization code to execute once when plperlu is first used."),
NULL,
&plperl_on_plperlu_init,
NULL,
PGC_SUSET, 0,
Revise the API for GUC variable assign hooks. The previous functions of assign hooks are now split between check hooks and assign hooks, where the former can fail but the latter shouldn't. Aside from being conceptually clearer, this approach exposes the "canonicalized" form of the variable value to guc.c without having to do an actual assignment. And that lets us fix the problem recently noted by Bernd Helmle that the auto-tune patch for wal_buffers resulted in bogus log messages about "parameter "wal_buffers" cannot be changed without restarting the server". There may be some speed advantage too, because this design lets hook functions avoid re-parsing variable values when restoring a previous state after a rollback (they can store a pre-parsed representation of the value instead). This patch also resolves a longstanding annoyance about custom error messages from variable assign hooks: they should modify, not appear separately from, guc.c's own message about "invalid parameter value".
2011-04-07 06:11:01 +02:00
NULL, NULL, NULL);
Add plperl.on_plperl_init and plperl.on_plperlu_init settings for language-specific startup. Rename recently added plperl.on_perl_init to plperl.on_init. Also, code cleanup for utf8 hack. Patch from Tim Bunce, reviewed by Alex Hunsaker.
2010-02-12 20:35:25 +01:00
Disallow setting bogus GUCs within an extension's reserved namespace. Commit 75d22069e tried to throw a warning for setting a custom GUC whose prefix belongs to a previously-loaded extension, if there is no such GUC defined by the extension. But that caused unstable behavior with parallel workers, because workers don't necessarily load extensions and GUCs in the same order their leader did. To make that work safely, we have to completely disallow the case. We now actually remove any such GUCs at the time of initial extension load, and then throw an error not just a warning if you try to add one later. While this might create a compatibility issue for a few people, the improvement in error-detection capability seems worth it; it's hard to believe that there's any good use-case for choosing such GUC names. This also un-reverts 5609cc01c (Rename EmitWarningsOnPlaceholders() to MarkGUCPrefixReserved()), since that function's old name is now even more of a misnomer. Florin Irion and Tom Lane Discussion: https://postgr.es/m/1902182.1640711215@sss.pgh.pa.us
2022-02-21 20:10:15 +01:00
MarkGUCPrefixReserved("plperl");
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
/*
* Create hash tables.
*/
hash_ctl.keysize = sizeof(Oid);
hash_ctl.entrysize = sizeof(plperl_interp_desc);
plperl_interp_hash = hash_create("PL/Perl interpreters",
8,
&hash_ctl,
Improve hash_create's API for selecting simple-binary-key hash functions. Previously, if you wanted anything besides C-string hash keys, you had to specify a custom hashing function to hash_create(). Nearly all such callers were specifying tag_hash or oid_hash; which is tedious, and rather error-prone, since a caller could easily miss the opportunity to optimize by using hash_uint32 when appropriate. Replace this with a design whereby callers using simple binary-data keys just specify HASH_BLOBS and don't need to mess with specific support functions. hash_create() itself will take care of optimizing when the key size is four bytes. This nets out saving a few hundred bytes of code space, and offers a measurable performance improvement in tidbitmap.c (which was not exploiting the opportunity to use hash_uint32 for its 4-byte keys). There might be some wins elsewhere too, I didn't analyze closely. In future we could look into offering a similar optimized hashing function for 8-byte keys. Under this design that could be done in a centralized and machine-independent fashion, whereas getting it right for keys of platform-dependent sizes would've been notationally painful before. For the moment, the old way still works fine, so as not to break source code compatibility for loadable modules. Eventually we might want to remove tag_hash and friends from the exported API altogether, since there's no real need for them to be explicitly referenced from outside dynahash.c. Teodor Sigaev and Tom Lane
2014-12-18 19:36:29 +01:00
HASH_ELEM | HASH_BLOBS);
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
hash_ctl.keysize = sizeof(plperl_proc_key);
hash_ctl.entrysize = sizeof(plperl_proc_ptr);
plperl_proc_hash = hash_create("PL/Perl procedures",
Force plperl and plperlu to run in separate interpreters. Create an error on an attempt to create the second interpreter if this is not supported by the perl installation. Per recent -hackers discussion.
2006-11-13 18:13:57 +01:00
32,
&hash_ctl,
Improve hash_create's API for selecting simple-binary-key hash functions. Previously, if you wanted anything besides C-string hash keys, you had to specify a custom hashing function to hash_create(). Nearly all such callers were specifying tag_hash or oid_hash; which is tedious, and rather error-prone, since a caller could easily miss the opportunity to optimize by using hash_uint32 when appropriate. Replace this with a design whereby callers using simple binary-data keys just specify HASH_BLOBS and don't need to mess with specific support functions. hash_create() itself will take care of optimizing when the key size is four bytes. This nets out saving a few hundred bytes of code space, and offers a measurable performance improvement in tidbitmap.c (which was not exploiting the opportunity to use hash_uint32 for its 4-byte keys). There might be some wins elsewhere too, I didn't analyze closely. In future we could look into offering a similar optimized hashing function for 8-byte keys. Under this design that could be done in a centralized and machine-independent fashion, whereas getting it right for keys of platform-dependent sizes would've been notationally painful before. For the moment, the old way still works fine, so as not to break source code compatibility for loadable modules. Eventually we might want to remove tag_hash and friends from the exported API altogether, since there's no real need for them to be explicitly referenced from outside dynahash.c. Teodor Sigaev and Tom Lane
2014-12-18 19:36:29 +01:00
HASH_ELEM | HASH_BLOBS);
Force plperl and plperlu to run in separate interpreters. Create an error on an attempt to create the second interpreter if this is not supported by the perl installation. Per recent -hackers discussion.
2006-11-13 18:13:57 +01:00
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
/*
* Save the default opmask.
*/
Abandon the use of Perl's Safe.pm to enforce restrictions in plperl, as it is fundamentally insecure. Instead apply an opmask to the whole interpreter that imposes restrictions on unsafe operations. These restrictions are much harder to subvert than is Safe.pm, since there is no container to be broken out of. Backported to release 7.4. In releases 7.4, 8.0 and 8.1 this also includes the necessary backporting of the two interpreters model for plperl and plperlu adopted in release 8.2. In versions 8.0 and up, the use of Perl's POSIX module to undo its locale mangling on Windows has become insecure with these changes, so it is replaced by our own routine, which is also faster. Nice side effects of the changes include that it is now possible to use perl's "strict" pragma in a natural way in plperl, and that perl's $a and $b variables now work as expected in sort routines, and that function compilation is significantly faster. Tim Bunce and Andrew Dunstan, with reviews from Alex Hunsaker and Alexey Klyukin. Security: CVE-2010-1169
2010-05-13 18:39:43 +02:00
PLPERL_SET_OPMASK(plperl_opmask);
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
/*
* Create the first Perl interpreter, but only partially initialize it.
*/
Tidy up and refactor plperl.c. - Changed MULTIPLICITY check from runtime to compiletime. No loads the large Config module. - Changed plperl_init_interp() to return new interp and not alter the global interp_state - Moved plperl_safe_init() call into check_interp(). - Removed plperl_safe_init_done state variable as interp_state now covers that role. - Changed plperl_create_sub() to take a plperl_proc_desc argument. - Simplified return value handling in plperl_create_sub. - Changed perl.com link in the docs to perl.org and tweaked wording to clarify that require, not use, is what's blocked. - Moved perl code in large multi-line C string literal macros out to plc_*.pl files. - Added a test2macro.pl utility to convert the plc_*.pl files to macros in a perlchunks.h file which is #included - Simplifed plperl_safe_init() slightly - Optimized pg_verifymbstr calls to avoid unneeded strlen()s. Patch from Tim Bunce, with minor editing from me.
2010-01-09 03:40:50 +01:00
plperl_held_interp = plperl_init_interp();
At 2005-05-21 20:18:50 +0530, ams@oryx.com wrote: > > > The second issue is where plperl returns a large result set. I have attached the following seven patches to address this problem: 1. Trivial. Replaces some errant spaces with tabs. 2. Trivial. Fixes the spelling of Jan's name, and gets rid of many inane, useless, annoying, and often misleading comments. Here's a sample: "plperl_init_all() - Initialize all". (I have tried to add some useful comments here and there, and will continue to do so now and again.) 3. Trivial. Splits up some long lines. 4. Converts SRFs in PL/Perl to use a Tuplestore and SFRM_Materialize to return the result set, based on the PL/PgSQL model. There are two major consequences: result sets will spill to disk when they can no longer fit in work_mem; and "select foo_srf()" no longer works. (I didn't lose sleep over the latter, since that form is not valid in PL/PgSQL, and it's not documented in PL/Perl.) 5. Trivial, but important. Fixes use of "undef" instead of undef. This would cause empty functions to fail in bizarre ways. I suspect that there's still another (old) bug here. I'll investigate further. 6. Moves the majority of (4) out into a new plperl_return_next() function, to make it possible to expose the functionality to Perl; cleans up some of the code besides. 7. Add an spi_return_next function for use in Perl code. If you want to apply the patches and try them out, 8-composite.diff is what you should use. (Note: my patches depend upon Andrew's use-strict and %_SHARED patches being applied.) Here's something to try: create or replace function foo() returns setof record as $$ $i = 0; for ("World", "PostgreSQL", "PL/Perl") { spi_return_next({f1=>++$i, f2=>'Hello', f3=>$_}); } return; $$ language plperl; select * from foo() as (f1 integer, f2 text, f3 text); (Many thanks to Andrews Dunstan and Supernews for their help.) Abhijit Menon-Sen
2005-06-04 22:33:06 +02:00
Add a feature for automatic initialization and finalization of dynamically loaded libraries: call functions _PG_init() and _PG_fini() if the library defines such symbols. Hence we no longer need to specify an initialization function in preload_libraries: we can assume that the library used the _PG_init() convention, instead. This removes one source of pilot error in use of preloaded libraries. Original patch by Ralf Engelschall, preload_libraries changes by me.
2006-08-08 21:15:09 +02:00
inited = true;
Cause library-preload feature to report error if specified initialization function is not found. Also, make all the PL libraries have initialization functions with standard names. Patch from Joe Conway.
2003-07-31 20:36:46 +02:00
}
Add plperl.on_perl_init setting to provide for initializing the perl library on load. Also, handle END blocks in plperl. Database access is disallowed during both these operations, although it might be allowed in END blocks in future. Patch from Tim Bunce.
2010-01-30 02:46:57 +01:00
Abandon the use of Perl's Safe.pm to enforce restrictions in plperl, as it is fundamentally insecure. Instead apply an opmask to the whole interpreter that imposes restrictions on unsafe operations. These restrictions are much harder to subvert than is Safe.pm, since there is no container to be broken out of. Backported to release 7.4. In releases 7.4, 8.0 and 8.1 this also includes the necessary backporting of the two interpreters model for plperl and plperlu adopted in release 8.2. In versions 8.0 and up, the use of Perl's POSIX module to undo its locale mangling on Windows has become insecure with these changes, so it is replaced by our own routine, which is also faster. Nice side effects of the changes include that it is now possible to use perl's "strict" pragma in a natural way in plperl, and that perl's $a and $b variables now work as expected in sort routines, and that function compilation is significantly faster. Tim Bunce and Andrew Dunstan, with reviews from Alex Hunsaker and Alexey Klyukin. Security: CVE-2010-1169
2010-05-13 18:39:43 +02:00
static void
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
set_interp_require(bool trusted)
Abandon the use of Perl's Safe.pm to enforce restrictions in plperl, as it is fundamentally insecure. Instead apply an opmask to the whole interpreter that imposes restrictions on unsafe operations. These restrictions are much harder to subvert than is Safe.pm, since there is no container to be broken out of. Backported to release 7.4. In releases 7.4, 8.0 and 8.1 this also includes the necessary backporting of the two interpreters model for plperl and plperlu adopted in release 8.2. In versions 8.0 and up, the use of Perl's POSIX module to undo its locale mangling on Windows has become insecure with these changes, so it is replaced by our own routine, which is also faster. Nice side effects of the changes include that it is now possible to use perl's "strict" pragma in a natural way in plperl, and that perl's $a and $b variables now work as expected in sort routines, and that function compilation is significantly faster. Tim Bunce and Andrew Dunstan, with reviews from Alex Hunsaker and Alexey Klyukin. Security: CVE-2010-1169
2010-05-13 18:39:43 +02:00
{
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
if (trusted)
Abandon the use of Perl's Safe.pm to enforce restrictions in plperl, as it is fundamentally insecure. Instead apply an opmask to the whole interpreter that imposes restrictions on unsafe operations. These restrictions are much harder to subvert than is Safe.pm, since there is no container to be broken out of. Backported to release 7.4. In releases 7.4, 8.0 and 8.1 this also includes the necessary backporting of the two interpreters model for plperl and plperlu adopted in release 8.2. In versions 8.0 and up, the use of Perl's POSIX module to undo its locale mangling on Windows has become insecure with these changes, so it is replaced by our own routine, which is also faster. Nice side effects of the changes include that it is now possible to use perl's "strict" pragma in a natural way in plperl, and that perl's $a and $b variables now work as expected in sort routines, and that function compilation is significantly faster. Tim Bunce and Andrew Dunstan, with reviews from Alex Hunsaker and Alexey Klyukin. Security: CVE-2010-1169
2010-05-13 18:39:43 +02:00
{
PL_ppaddr[OP_REQUIRE] = pp_require_safe;
PL_ppaddr[OP_DOFILE] = pp_require_safe;
}
else
{
PL_ppaddr[OP_REQUIRE] = pp_require_orig;
PL_ppaddr[OP_DOFILE] = pp_require_orig;
}
}
Add plperl.on_perl_init setting to provide for initializing the perl library on load. Also, handle END blocks in plperl. Database access is disallowed during both these operations, although it might be allowed in END blocks in future. Patch from Tim Bunce.
2010-01-30 02:46:57 +01:00
/*
* Cleanup perl interpreters, including running END blocks.
* Does not fully undo the actions of _PG_init() nor make it callable again.
*/
static void
plperl_fini(int code, Datum arg)
{
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
HASH_SEQ_STATUS hash_seq;
plperl_interp_desc *interp_desc;
Add plperl.on_perl_init setting to provide for initializing the perl library on load. Also, handle END blocks in plperl. Database access is disallowed during both these operations, although it might be allowed in END blocks in future. Patch from Tim Bunce.
2010-01-30 02:46:57 +01:00
elog(DEBUG3, "plperl_fini");
/*
Add plperl.on_plperl_init and plperl.on_plperlu_init settings for language-specific startup. Rename recently added plperl.on_perl_init to plperl.on_init. Also, code cleanup for utf8 hack. Patch from Tim Bunce, reviewed by Alex Hunsaker.
2010-02-12 20:35:25 +01:00
* Indicate that perl is terminating. Disables use of spi_* functions when
* running END/DESTROY code. See check_spi_usage_allowed(). Could be
Add plperl.on_perl_init setting to provide for initializing the perl library on load. Also, handle END blocks in plperl. Database access is disallowed during both these operations, although it might be allowed in END blocks in future. Patch from Tim Bunce.
2010-01-30 02:46:57 +01:00
* enabled in future, with care, using a transaction
* http://archives.postgresql.org/pgsql-hackers/2010-01/msg02743.php
*/
plperl_ending = true;
/* Only perform perl cleanup if we're exiting cleanly */
if (code)
{
elog(DEBUG3, "plperl_fini: skipped");
return;
}
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
/* Zap the "held" interpreter, if we still have it */
Add plperl.on_perl_init setting to provide for initializing the perl library on load. Also, handle END blocks in plperl. Database access is disallowed during both these operations, although it might be allowed in END blocks in future. Patch from Tim Bunce.
2010-01-30 02:46:57 +01:00
plperl_destroy_interp(&plperl_held_interp);
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
/* Zap any fully-initialized interpreters */
hash_seq_init(&hash_seq, plperl_interp_hash);
while ((interp_desc = hash_seq_search(&hash_seq)) != NULL)
{
if (interp_desc->interp)
{
activate_interpreter(interp_desc);
plperl_destroy_interp(&interp_desc->interp);
}
}
Add plperl.on_perl_init setting to provide for initializing the perl library on load. Also, handle END blocks in plperl. Database access is disallowed during both these operations, although it might be allowed in END blocks in future. Patch from Tim Bunce.
2010-01-30 02:46:57 +01:00
elog(DEBUG3, "plperl_fini: done");
}
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
/*
* Select and activate an appropriate Perl interpreter.
Force plperl and plperlu to run in separate interpreters. Create an error on an attempt to create the second interpreter if this is not supported by the perl installation. Per recent -hackers discussion.
2006-11-13 18:13:57 +01:00
*/
Combine cmin and cmax fields of HeapTupleHeaders into a single field, by keeping private state in each backend that has inserted and deleted the same tuple during its current top-level transaction. This is sufficient since there is no need to be able to determine the cmin/cmax from any other transaction. This gets us back down to 23-byte headers, removing a penalty paid in 8.0 to support subtransactions. Patch by Heikki Linnakangas, with minor revisions by moi, following a design hashed out awhile back on the pghackers list.
2007-02-09 04:35:35 +01:00
static void
Various small improvements and cleanups for PL/Perl. - Allow (ineffective) use of 'require' in plperl If the required module is not already loaded then it dies. So "use strict;" now works in plperl. - Pre-load the feature module if perl >= 5.10. So "use feature :5.10;" now works in plperl. - Stored procedure subs are now given names. The names are not visible in ordinary use, but they make tools like Devel::NYTProf and Devel::Cover much more useful. - Simplified and generalized the subroutine creation code. Now one code path for generating sub source code, not four. Can generate multiple 'use' statements with specific imports (which handles plperl.use_strict currently and can easily be extended to handle a plperl.use_feature=':5.12' in future). - Disallows use of Safe version 2.20 which is broken for PL/Perl. http://rt.perl.org/rt3/Ticket/Display.html?id=72068 - Assorted minor optimizations by pre-growing data structures. Patch from Tim Bunce, reviewed by Alex Hunsaker.
2010-01-27 00:11:56 +01:00
select_perl_context(bool trusted)
Force plperl and plperlu to run in separate interpreters. Create an error on an attempt to create the second interpreter if this is not supported by the perl installation. Per recent -hackers discussion.
2006-11-13 18:13:57 +01:00
{
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
Oid user_id;
plperl_interp_desc *interp_desc;
bool found;
PerlInterpreter *interp = NULL;
/* Find or create the interpreter hashtable entry for this userid */
if (trusted)
user_id = GetUserId();
else
user_id = InvalidOid;
interp_desc = hash_search(plperl_interp_hash, &user_id,
HASH_ENTER,
&found);
if (!found)
{
/* Initialize newly-created hashtable entry */
interp_desc->interp = NULL;
interp_desc->query_hash = NULL;
}
/* Make sure we have a query_hash for this interpreter */
if (interp_desc->query_hash == NULL)
{
HASHCTL hash_ctl;
hash_ctl.keysize = NAMEDATALEN;
hash_ctl.entrysize = sizeof(plperl_query_entry);
interp_desc->query_hash = hash_create("PL/Perl queries",
32,
&hash_ctl,
Improve hash_create()'s API for some added robustness. Invent a new flag bit HASH_STRINGS to specify C-string hashing, which was formerly the default; and add assertions insisting that exactly one of the bits HASH_STRINGS, HASH_BLOBS, and HASH_FUNCTION be set. This is in hopes of preventing recurrences of the type of oversight fixed in commit a1b8aa1e4 (i.e., mistakenly omitting HASH_BLOBS). Also, when HASH_STRINGS is specified, insist that the keysize be more than 8 bytes. This is a heuristic, but it should catch accidental use of HASH_STRINGS for integer or pointer keys. (Nearly all existing use-cases set the keysize to NAMEDATALEN or more, so there's little reason to think this restriction should be problematic.) Tweak hash_create() to insist that the HASH_ELEM flag be set, and remove the defaults it had for keysize and entrysize. Since those defaults were undocumented and basically useless, no callers omitted HASH_ELEM anyway. Also, remove memset's zeroing the HASHCTL parameter struct from those callers that had one. This has never been really necessary, and while it wasn't a bad coding convention it was confusing that some callers did it and some did not. We might as well save a few cycles by standardizing on "not". Also improve the documentation for hash_create(). In passing, improve reinit.c's usage of a hash table by storing the key as a binary Oid rather than a string; and, since that's a temporary hash table, allocate it in CurrentMemoryContext for neatness. Discussion: https://postgr.es/m/590625.1607878171@sss.pgh.pa.us
2020-12-15 17:38:53 +01:00
HASH_ELEM | HASH_STRINGS);
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
}
Add plperl.on_perl_init setting to provide for initializing the perl library on load. Also, handle END blocks in plperl. Database access is disallowed during both these operations, although it might be allowed in END blocks in future. Patch from Tim Bunce.
2010-01-30 02:46:57 +01:00
Various small improvements and cleanups for PL/Perl. - Allow (ineffective) use of 'require' in plperl If the required module is not already loaded then it dies. So "use strict;" now works in plperl. - Pre-load the feature module if perl >= 5.10. So "use feature :5.10;" now works in plperl. - Stored procedure subs are now given names. The names are not visible in ordinary use, but they make tools like Devel::NYTProf and Devel::Cover much more useful. - Simplified and generalized the subroutine creation code. Now one code path for generating sub source code, not four. Can generate multiple 'use' statements with specific imports (which handles plperl.use_strict currently and can easily be extended to handle a plperl.use_feature=':5.12' in future). - Disallows use of Safe version 2.20 which is broken for PL/Perl. http://rt.perl.org/rt3/Ticket/Display.html?id=72068 - Assorted minor optimizations by pre-growing data structures. Patch from Tim Bunce, reviewed by Alex Hunsaker.
2010-01-27 00:11:56 +01:00
/*
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
* Quick exit if already have an interpreter
Various small improvements and cleanups for PL/Perl. - Allow (ineffective) use of 'require' in plperl If the required module is not already loaded then it dies. So "use strict;" now works in plperl. - Pre-load the feature module if perl >= 5.10. So "use feature :5.10;" now works in plperl. - Stored procedure subs are now given names. The names are not visible in ordinary use, but they make tools like Devel::NYTProf and Devel::Cover much more useful. - Simplified and generalized the subroutine creation code. Now one code path for generating sub source code, not four. Can generate multiple 'use' statements with specific imports (which handles plperl.use_strict currently and can easily be extended to handle a plperl.use_feature=':5.12' in future). - Disallows use of Safe version 2.20 which is broken for PL/Perl. http://rt.perl.org/rt3/Ticket/Display.html?id=72068 - Assorted minor optimizations by pre-growing data structures. Patch from Tim Bunce, reviewed by Alex Hunsaker.
2010-01-27 00:11:56 +01:00
*/
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
if (interp_desc->interp)
{
activate_interpreter(interp_desc);
Various small improvements and cleanups for PL/Perl. - Allow (ineffective) use of 'require' in plperl If the required module is not already loaded then it dies. So "use strict;" now works in plperl. - Pre-load the feature module if perl >= 5.10. So "use feature :5.10;" now works in plperl. - Stored procedure subs are now given names. The names are not visible in ordinary use, but they make tools like Devel::NYTProf and Devel::Cover much more useful. - Simplified and generalized the subroutine creation code. Now one code path for generating sub source code, not four. Can generate multiple 'use' statements with specific imports (which handles plperl.use_strict currently and can easily be extended to handle a plperl.use_feature=':5.12' in future). - Disallows use of Safe version 2.20 which is broken for PL/Perl. http://rt.perl.org/rt3/Ticket/Display.html?id=72068 - Assorted minor optimizations by pre-growing data structures. Patch from Tim Bunce, reviewed by Alex Hunsaker.
2010-01-27 00:11:56 +01:00
return;
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
}
Various small improvements and cleanups for PL/Perl. - Allow (ineffective) use of 'require' in plperl If the required module is not already loaded then it dies. So "use strict;" now works in plperl. - Pre-load the feature module if perl >= 5.10. So "use feature :5.10;" now works in plperl. - Stored procedure subs are now given names. The names are not visible in ordinary use, but they make tools like Devel::NYTProf and Devel::Cover much more useful. - Simplified and generalized the subroutine creation code. Now one code path for generating sub source code, not four. Can generate multiple 'use' statements with specific imports (which handles plperl.use_strict currently and can easily be extended to handle a plperl.use_feature=':5.12' in future). - Disallows use of Safe version 2.20 which is broken for PL/Perl. http://rt.perl.org/rt3/Ticket/Display.html?id=72068 - Assorted minor optimizations by pre-growing data structures. Patch from Tim Bunce, reviewed by Alex Hunsaker.
2010-01-27 00:11:56 +01:00
/*
* adopt held interp if free, else create new one if possible
*/
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
if (plperl_held_interp != NULL)
Force plperl and plperlu to run in separate interpreters. Create an error on an attempt to create the second interpreter if this is not supported by the perl installation. Per recent -hackers discussion.
2006-11-13 18:13:57 +01:00
{
Add plperl.on_perl_init setting to provide for initializing the perl library on load. Also, handle END blocks in plperl. Database access is disallowed during both these operations, although it might be allowed in END blocks in future. Patch from Tim Bunce.
2010-01-30 02:46:57 +01:00
/* first actual use of a perl interpreter */
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
interp = plperl_held_interp;
/*
* Reset the plperl_held_interp pointer first; if we fail during init
* we don't want to try again with the partially-initialized interp.
*/
plperl_held_interp = NULL;
Add plperl.on_perl_init setting to provide for initializing the perl library on load. Also, handle END blocks in plperl. Database access is disallowed during both these operations, although it might be allowed in END blocks in future. Patch from Tim Bunce.
2010-01-30 02:46:57 +01:00
Force plperl and plperlu to run in separate interpreters. Create an error on an attempt to create the second interpreter if this is not supported by the perl installation. Per recent -hackers discussion.
2006-11-13 18:13:57 +01:00
if (trusted)
Add plperl.on_plperl_init and plperl.on_plperlu_init settings for language-specific startup. Rename recently added plperl.on_perl_init to plperl.on_init. Also, code cleanup for utf8 hack. Patch from Tim Bunce, reviewed by Alex Hunsaker.
2010-02-12 20:35:25 +01:00
plperl_trusted_init();
Force plperl and plperlu to run in separate interpreters. Create an error on an attempt to create the second interpreter if this is not supported by the perl installation. Per recent -hackers discussion.
2006-11-13 18:13:57 +01:00
else
Add plperl.on_plperl_init and plperl.on_plperlu_init settings for language-specific startup. Rename recently added plperl.on_perl_init to plperl.on_init. Also, code cleanup for utf8 hack. Patch from Tim Bunce, reviewed by Alex Hunsaker.
2010-02-12 20:35:25 +01:00
plperl_untrusted_init();
Clean up package namespace use and use of Safe in plperl. Prevent use of another buggy version of Safe.pm. Only register the exit handler if we have successfully created an interpreter. Change log level of perl warnings from NOTICE to WARNING. The infrastructure is there if in future we decide to allow DBAs to specify extra modules that will be allowed in trusted code. However, for now the relevant variables are declared as lexicals rather than as package variables, so that they are not (or should not be) accessible. Mostly code from Tim Bunce, reviewed by Alex Hunsaker, with some tweaks by me.
2010-02-16 22:39:52 +01:00
/* successfully initialized, so arrange for cleanup */
on_proc_exit(plperl_fini, 0);
Force plperl and plperlu to run in separate interpreters. Create an error on an attempt to create the second interpreter if this is not supported by the perl installation. Per recent -hackers discussion.
2006-11-13 18:13:57 +01:00
}
Tidy up and refactor plperl.c. - Changed MULTIPLICITY check from runtime to compiletime. No loads the large Config module. - Changed plperl_init_interp() to return new interp and not alter the global interp_state - Moved plperl_safe_init() call into check_interp(). - Removed plperl_safe_init_done state variable as interp_state now covers that role. - Changed plperl_create_sub() to take a plperl_proc_desc argument. - Simplified return value handling in plperl_create_sub. - Changed perl.com link in the docs to perl.org and tweaked wording to clarify that require, not use, is what's blocked. - Moved perl code in large multi-line C string literal macros out to plc_*.pl files. - Added a test2macro.pl utility to convert the plc_*.pl files to macros in a perlchunks.h file which is #included - Simplifed plperl_safe_init() slightly - Optimized pg_verifymbstr calls to avoid unneeded strlen()s. Patch from Tim Bunce, with minor editing from me.
2010-01-09 03:40:50 +01:00
else
Force plperl and plperlu to run in separate interpreters. Create an error on an attempt to create the second interpreter if this is not supported by the perl installation. Per recent -hackers discussion.
2006-11-13 18:13:57 +01:00
{
Tidy up and refactor plperl.c. - Changed MULTIPLICITY check from runtime to compiletime. No loads the large Config module. - Changed plperl_init_interp() to return new interp and not alter the global interp_state - Moved plperl_safe_init() call into check_interp(). - Removed plperl_safe_init_done state variable as interp_state now covers that role. - Changed plperl_create_sub() to take a plperl_proc_desc argument. - Simplified return value handling in plperl_create_sub. - Changed perl.com link in the docs to perl.org and tweaked wording to clarify that require, not use, is what's blocked. - Moved perl code in large multi-line C string literal macros out to plc_*.pl files. - Added a test2macro.pl utility to convert the plc_*.pl files to macros in a perlchunks.h file which is #included - Simplifed plperl_safe_init() slightly - Optimized pg_verifymbstr calls to avoid unneeded strlen()s. Patch from Tim Bunce, with minor editing from me.
2010-01-09 03:40:50 +01:00
#ifdef MULTIPLICITY
pgindent run on plperl.c
2011-02-17 20:40:13 +01:00
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
/*
* plperl_init_interp will change Perl's idea of the active
* interpreter. Reset plperl_active_interp temporarily, so that if we
* hit an error partway through here, we'll make sure to switch back
* to a non-broken interpreter before running any other Perl
* functions.
*/
plperl_active_interp = NULL;
/* Now build the new interpreter */
interp = plperl_init_interp();
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
Add plperl.on_plperl_init and plperl.on_plperlu_init settings for language-specific startup. Rename recently added plperl.on_perl_init to plperl.on_init. Also, code cleanup for utf8 hack. Patch from Tim Bunce, reviewed by Alex Hunsaker.
2010-02-12 20:35:25 +01:00
if (trusted)
plperl_trusted_init();
else
plperl_untrusted_init();
Tidy up and refactor plperl.c. - Changed MULTIPLICITY check from runtime to compiletime. No loads the large Config module. - Changed plperl_init_interp() to return new interp and not alter the global interp_state - Moved plperl_safe_init() call into check_interp(). - Removed plperl_safe_init_done state variable as interp_state now covers that role. - Changed plperl_create_sub() to take a plperl_proc_desc argument. - Simplified return value handling in plperl_create_sub. - Changed perl.com link in the docs to perl.org and tweaked wording to clarify that require, not use, is what's blocked. - Moved perl code in large multi-line C string literal macros out to plc_*.pl files. - Added a test2macro.pl utility to convert the plc_*.pl files to macros in a perlchunks.h file which is #included - Simplifed plperl_safe_init() slightly - Optimized pg_verifymbstr calls to avoid unneeded strlen()s. Patch from Tim Bunce, with minor editing from me.
2010-01-09 03:40:50 +01:00
#else
Fix thinko: errmsg -> ereport. Silly mistake in my commit 09cecdf285ea9f51, reported by Erik Rijkers. The fact that the buildfarm didn't find this implies that we are not testing Perl builds that lack MULTIPLICITY, which is a bit disturbing from a coverage standpoint. Until today I'd have said nobody cared about such configurations anymore; but maybe not.
2015-11-19 20:16:39 +01:00
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("cannot allocate multiple Perl interpreters on this platform")));
Tidy up and refactor plperl.c. - Changed MULTIPLICITY check from runtime to compiletime. No loads the large Config module. - Changed plperl_init_interp() to return new interp and not alter the global interp_state - Moved plperl_safe_init() call into check_interp(). - Removed plperl_safe_init_done state variable as interp_state now covers that role. - Changed plperl_create_sub() to take a plperl_proc_desc argument. - Simplified return value handling in plperl_create_sub. - Changed perl.com link in the docs to perl.org and tweaked wording to clarify that require, not use, is what's blocked. - Moved perl code in large multi-line C string literal macros out to plc_*.pl files. - Added a test2macro.pl utility to convert the plc_*.pl files to macros in a perlchunks.h file which is #included - Simplifed plperl_safe_init() slightly - Optimized pg_verifymbstr calls to avoid unneeded strlen()s. Patch from Tim Bunce, with minor editing from me.
2010-01-09 03:40:50 +01:00
#endif
Force plperl and plperlu to run in separate interpreters. Create an error on an attempt to create the second interpreter if this is not supported by the perl installation. Per recent -hackers discussion.
2006-11-13 18:13:57 +01:00
}
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
set_interp_require(trusted);
Various small improvements and cleanups for PL/Perl. - Allow (ineffective) use of 'require' in plperl If the required module is not already loaded then it dies. So "use strict;" now works in plperl. - Pre-load the feature module if perl >= 5.10. So "use feature :5.10;" now works in plperl. - Stored procedure subs are now given names. The names are not visible in ordinary use, but they make tools like Devel::NYTProf and Devel::Cover much more useful. - Simplified and generalized the subroutine creation code. Now one code path for generating sub source code, not four. Can generate multiple 'use' statements with specific imports (which handles plperl.use_strict currently and can easily be extended to handle a plperl.use_feature=':5.12' in future). - Disallows use of Safe version 2.20 which is broken for PL/Perl. http://rt.perl.org/rt3/Ticket/Display.html?id=72068 - Assorted minor optimizations by pre-growing data structures. Patch from Tim Bunce, reviewed by Alex Hunsaker.
2010-01-27 00:11:56 +01:00
/*
Add plperl.on_plperl_init and plperl.on_plperlu_init settings for language-specific startup. Rename recently added plperl.on_perl_init to plperl.on_init. Also, code cleanup for utf8 hack. Patch from Tim Bunce, reviewed by Alex Hunsaker.
2010-02-12 20:35:25 +01:00
* Since the timing of first use of PL/Perl can't be predicted, any
* database interaction during initialization is problematic. Including,
* but not limited to, security definer issues. So we only enable access
* to the database AFTER on_*_init code has run. See
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
* http://archives.postgresql.org/pgsql-hackers/2010-01/msg02669.php
Add plperl.on_perl_init setting to provide for initializing the perl library on load. Also, handle END blocks in plperl. Database access is disallowed during both these operations, although it might be allowed in END blocks in future. Patch from Tim Bunce.
2010-01-30 02:46:57 +01:00
*/
PL/Perl portability fix: avoid including XSUB.h in plperl.c. In Perl builds that define PERL_IMPLICIT_SYS, XSUB.h defines macros that replace a whole lot of basic libc functions with Perl functions. We can't tolerate that in plperl.c; it breaks at least PG_TRY and probably other stuff. The core idea of this patch is to include XSUB.h only in the .xs files where it's really needed, and to move any code broken by PERL_IMPLICIT_SYS out of the .xs files and into plperl.c. The reason this hasn't been a problem before is that our build techniques did not result in PERL_IMPLICIT_SYS appearing as a #define in PL/Perl, even on some platforms where Perl thinks it is defined. That's about to change in order to fix a nasty portability issue, so we need this work to make the code safe for that. Rather unaccountably, the Perl people chose XSUB.h as the place to provide the versions of the aTHX/aTHX_ macros that are needed by code that's not explicitly aware of the MULTIPLICITY API conventions. Hence, just removing XSUB.h from plperl.c fails miserably. But we can work around that by defining PERL_NO_GET_CONTEXT (which would make the relevant stanza of XSUB.h a no-op anyway). As explained in perlguts.pod, that means we need to add a "dTHX" macro call in every C function that calls a Perl API function. In most of them we just add this at the top; but since the macro fetches the current Perl interpreter pointer, more care is needed in functions that switch the active interpreter. Lack of the macro is easily recognized since it results in bleats about "my_perl" not being defined. (A nice side benefit of this is that it significantly reduces the number of fetches of the current interpreter pointer. On my machine, plperl.so gets more than 10% smaller, and there's probably some performance win too. We could reduce the number of fetches still more by decorating the code with pTHX_/aTHX_ macros to pass the interpreter pointer around, as explained by perlguts.pod; but that's a task for another day.) Formatting note: pgindent seems happy to treat "dTHX;" as a declaration so long as it's the first thing after the left brace, as we'd already observed with respect to the similar macro "dSP;". If you try to put it later in a set of declarations, pgindent puts ugly extra space around it. Having removed XSUB.h from plperl.c, we need only move the support functions for spi_return_next and util_elog (both of which use PG_TRY) out of the .xs files and into plperl.c. This seems sufficient to avoid the known problems caused by PERL_IMPLICIT_SYS, although we could move more code if additional issues emerge. This will need to be back-patched, but first let's see what the buildfarm makes of it. Patch by me, with some help from Ashutosh Sharma Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
2017-07-28 18:25:43 +02:00
{
dTHX;
Add plperl.on_perl_init setting to provide for initializing the perl library on load. Also, handle END blocks in plperl. Database access is disallowed during both these operations, although it might be allowed in END blocks in future. Patch from Tim Bunce.
2010-01-30 02:46:57 +01:00
PL/Perl portability fix: avoid including XSUB.h in plperl.c. In Perl builds that define PERL_IMPLICIT_SYS, XSUB.h defines macros that replace a whole lot of basic libc functions with Perl functions. We can't tolerate that in plperl.c; it breaks at least PG_TRY and probably other stuff. The core idea of this patch is to include XSUB.h only in the .xs files where it's really needed, and to move any code broken by PERL_IMPLICIT_SYS out of the .xs files and into plperl.c. The reason this hasn't been a problem before is that our build techniques did not result in PERL_IMPLICIT_SYS appearing as a #define in PL/Perl, even on some platforms where Perl thinks it is defined. That's about to change in order to fix a nasty portability issue, so we need this work to make the code safe for that. Rather unaccountably, the Perl people chose XSUB.h as the place to provide the versions of the aTHX/aTHX_ macros that are needed by code that's not explicitly aware of the MULTIPLICITY API conventions. Hence, just removing XSUB.h from plperl.c fails miserably. But we can work around that by defining PERL_NO_GET_CONTEXT (which would make the relevant stanza of XSUB.h a no-op anyway). As explained in perlguts.pod, that means we need to add a "dTHX" macro call in every C function that calls a Perl API function. In most of them we just add this at the top; but since the macro fetches the current Perl interpreter pointer, more care is needed in functions that switch the active interpreter. Lack of the macro is easily recognized since it results in bleats about "my_perl" not being defined. (A nice side benefit of this is that it significantly reduces the number of fetches of the current interpreter pointer. On my machine, plperl.so gets more than 10% smaller, and there's probably some performance win too. We could reduce the number of fetches still more by decorating the code with pTHX_/aTHX_ macros to pass the interpreter pointer around, as explained by perlguts.pod; but that's a task for another day.) Formatting note: pgindent seems happy to treat "dTHX;" as a declaration so long as it's the first thing after the left brace, as we'd already observed with respect to the similar macro "dSP;". If you try to put it later in a set of declarations, pgindent puts ugly extra space around it. Having removed XSUB.h from plperl.c, we need only move the support functions for spi_return_next and util_elog (both of which use PG_TRY) out of the .xs files and into plperl.c. This seems sufficient to avoid the known problems caused by PERL_IMPLICIT_SYS, although we could move more code if additional issues emerge. This will need to be back-patched, but first let's see what the buildfarm makes of it. Patch by me, with some help from Ashutosh Sharma Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
2017-07-28 18:25:43 +02:00
newXS("PostgreSQL::InServer::SPI::bootstrap",
boot_PostgreSQL__InServer__SPI, __FILE__);
eval_pv("PostgreSQL::InServer::SPI::bootstrap()", FALSE);
if (SvTRUE(ERRSV))
ereport(ERROR,
(errcode(ERRCODE_EXTERNAL_ROUTINE_EXCEPTION),
errmsg("%s", strip_trailing_ws(sv2cstr(ERRSV))),
errcontext("while executing PostgreSQL::InServer::SPI::bootstrap")));
}
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
/* Fully initialized, so mark the hashtable entry valid */
interp_desc->interp = interp;
/* And mark this as the active interpreter */
plperl_active_interp = interp_desc;
Force plperl and plperlu to run in separate interpreters. Create an error on an attempt to create the second interpreter if this is not supported by the perl installation. Per recent -hackers discussion.
2006-11-13 18:13:57 +01:00
}
Ensure the previous Perl interpreter selection is restored upon exit from plperl_call_handler, in both the normal and error-exit paths. Per report from Alexey Klyukin.
2009-10-31 19:11:59 +01:00
/*
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
* Make the specified interpreter the active one
*
* A call with NULL does nothing. This is so that "restoring" to a previously
* null state of plperl_active_interp doesn't result in useless thrashing.
Ensure the previous Perl interpreter selection is restored upon exit from plperl_call_handler, in both the normal and error-exit paths. Per report from Alexey Klyukin.
2009-10-31 19:11:59 +01:00
*/
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
static void
activate_interpreter(plperl_interp_desc *interp_desc)
Force plperl and plperlu to run in separate interpreters. Create an error on an attempt to create the second interpreter if this is not supported by the perl installation. Per recent -hackers discussion.
2006-11-13 18:13:57 +01:00
{
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
if (interp_desc && plperl_active_interp != interp_desc)
Force plperl and plperlu to run in separate interpreters. Create an error on an attempt to create the second interpreter if this is not supported by the perl installation. Per recent -hackers discussion.
2006-11-13 18:13:57 +01:00
{
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
Assert(interp_desc->interp);
PERL_SET_CONTEXT(interp_desc->interp);
/* trusted iff user_id isn't InvalidOid */
set_interp_require(OidIsValid(interp_desc->user_id));
plperl_active_interp = interp_desc;
Force plperl and plperlu to run in separate interpreters. Create an error on an attempt to create the second interpreter if this is not supported by the perl installation. Per recent -hackers discussion.
2006-11-13 18:13:57 +01:00
}
}
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
/*
* Create a new Perl interpreter.
*
* We initialize the interpreter as far as we can without knowing whether
* it will become a trusted or untrusted interpreter; in particular, the
* plperl.on_init code will get executed. Later, either plperl_trusted_init
* or plperl_untrusted_init must be called to complete the initialization.
*/
Tidy up and refactor plperl.c. - Changed MULTIPLICITY check from runtime to compiletime. No loads the large Config module. - Changed plperl_init_interp() to return new interp and not alter the global interp_state - Moved plperl_safe_init() call into check_interp(). - Removed plperl_safe_init_done state variable as interp_state now covers that role. - Changed plperl_create_sub() to take a plperl_proc_desc argument. - Simplified return value handling in plperl_create_sub. - Changed perl.com link in the docs to perl.org and tweaked wording to clarify that require, not use, is what's blocked. - Moved perl code in large multi-line C string literal macros out to plc_*.pl files. - Added a test2macro.pl utility to convert the plc_*.pl files to macros in a perlchunks.h file which is #included - Simplifed plperl_safe_init() slightly - Optimized pg_verifymbstr calls to avoid unneeded strlen()s. Patch from Tim Bunce, with minor editing from me.
2010-01-09 03:40:50 +01:00
static PerlInterpreter *
Well, after persuading cvsup and cvs that it _is_ possible to have local modifiable repositories, I have a clean untrusted plperl patch to offer you :) Highlights: * There's one perl interpreter used for both trusted and untrusted procedures. I do think its unnecessary to keep two perl interpreters around. If someone can break out from trusted "Safe" perl mode, well, they can do what they want already. If someone disagrees, I can change this. * Opcode is not statically loaded anymore. Instead, we load Dynaloader, which then can grab Opcode (and anything else you can 'use') on its own. * Checked to work on FreeBSD 4.3 + perl 5.5.3 , OpenBSD 2.8 + perl5.6.1, RedHat 6.2 + perl 5.5.3 * Uses ExtUtils::Embed to find what options are necessary to link with perl shared libraries * createlang is also updated, it can create untrusted perl using 'plperlu' * Example script (assuming you have Mail::Sendmail installed): create function foo() returns text as ' use Mail::Sendmail; %mail = ( To => q(you@yourname.com), From => q(me@here.com), Message => "This is a very short message" ); sendmail(%mail) or die $Mail::Sendmail::error; return "OK. Log says:\n", $Mail::Sendmail::log; ' language 'plperlu'; Alex Pilosov
2001-06-18 23:40:06 +02:00
plperl_init_interp(void)
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
{
Tidy up and refactor plperl.c. - Changed MULTIPLICITY check from runtime to compiletime. No loads the large Config module. - Changed plperl_init_interp() to return new interp and not alter the global interp_state - Moved plperl_safe_init() call into check_interp(). - Removed plperl_safe_init_done state variable as interp_state now covers that role. - Changed plperl_create_sub() to take a plperl_proc_desc argument. - Simplified return value handling in plperl_create_sub. - Changed perl.com link in the docs to perl.org and tweaked wording to clarify that require, not use, is what's blocked. - Moved perl code in large multi-line C string literal macros out to plc_*.pl files. - Added a test2macro.pl utility to convert the plc_*.pl files to macros in a perlchunks.h file which is #included - Simplifed plperl_safe_init() slightly - Optimized pg_verifymbstr calls to avoid unneeded strlen()s. Patch from Tim Bunce, with minor editing from me.
2010-01-09 03:40:50 +01:00
PerlInterpreter *plperl;
Add plperl.on_perl_init setting to provide for initializing the perl library on load. Also, handle END blocks in plperl. Database access is disallowed during both these operations, although it might be allowed in END blocks in future. Patch from Tim Bunce.
2010-01-30 02:46:57 +01:00
static char *embedding[3 + 2] = {
Tidy up and refactor plperl.c. - Changed MULTIPLICITY check from runtime to compiletime. No loads the large Config module. - Changed plperl_init_interp() to return new interp and not alter the global interp_state - Moved plperl_safe_init() call into check_interp(). - Removed plperl_safe_init_done state variable as interp_state now covers that role. - Changed plperl_create_sub() to take a plperl_proc_desc argument. - Simplified return value handling in plperl_create_sub. - Changed perl.com link in the docs to perl.org and tweaked wording to clarify that require, not use, is what's blocked. - Moved perl code in large multi-line C string literal macros out to plc_*.pl files. - Added a test2macro.pl utility to convert the plc_*.pl files to macros in a perlchunks.h file which is #included - Simplifed plperl_safe_init() slightly - Optimized pg_verifymbstr calls to avoid unneeded strlen()s. Patch from Tim Bunce, with minor editing from me.
2010-01-09 03:40:50 +01:00
"", "-e", PLC_PERLBOOT
At 2005-05-21 20:18:50 +0530, ams@oryx.com wrote: > > > The second issue is where plperl returns a large result set. I have attached the following seven patches to address this problem: 1. Trivial. Replaces some errant spaces with tabs. 2. Trivial. Fixes the spelling of Jan's name, and gets rid of many inane, useless, annoying, and often misleading comments. Here's a sample: "plperl_init_all() - Initialize all". (I have tried to add some useful comments here and there, and will continue to do so now and again.) 3. Trivial. Splits up some long lines. 4. Converts SRFs in PL/Perl to use a Tuplestore and SFRM_Materialize to return the result set, based on the PL/PgSQL model. There are two major consequences: result sets will spill to disk when they can no longer fit in work_mem; and "select foo_srf()" no longer works. (I didn't lose sleep over the latter, since that form is not valid in PL/PgSQL, and it's not documented in PL/Perl.) 5. Trivial, but important. Fixes use of "undef" instead of undef. This would cause empty functions to fail in bizarre ways. I suspect that there's still another (old) bug here. I'll investigate further. 6. Moves the majority of (4) out into a new plperl_return_next() function, to make it possible to expose the functionality to Perl; cleans up some of the code besides. 7. Add an spi_return_next function for use in Perl code. If you want to apply the patches and try them out, 8-composite.diff is what you should use. (Note: my patches depend upon Andrew's use-strict and %_SHARED patches being applied.) Here's something to try: create or replace function foo() returns setof record as $$ $i = 0; for ("World", "PostgreSQL", "PL/Perl") { spi_return_next({f1=>++$i, f2=>'Hello', f3=>$_}); } return; $$ language plperl; select * from foo() as (f1 integer, f2 text, f3 text); (Many thanks to Andrews Dunstan and Supernews for their help.) Abhijit Menon-Sen
2005-06-04 22:33:06 +02:00
};
Initialise perl library as documented in perl API. Backpatch to release 7.4.
2009-06-04 17:59:55 +02:00
int nargs = 3;
Undo perl's nasty locale setting on Windows. Since we can't do that as elsewhere by setting the environment appropriately, we make perl do it right after interpreter startup by calling its POSIX::setlocale().
2006-01-28 17:20:31 +01:00
#ifdef WIN32
pgindent run for 9.4 This includes removing tabs after periods in C comments, which was applied to back branches, so this change should not effect backpatching.
2014-05-06 18:12:18 +02:00
Undo perl's nasty locale setting on Windows. Since we can't do that as elsewhere by setting the environment appropriately, we make perl do it right after interpreter startup by calling its POSIX::setlocale().
2006-01-28 17:20:31 +01:00
/*
* The perl library on startup does horrible things like call
* setlocale(LC_ALL,""). We have protected against that on most platforms
* by setting the environment appropriately. However, on Windows,
* setlocale() does not consult the environment, so we need to save the
* existing locale settings before perl has a chance to mangle them and
* restore them after its dirty deeds are done.
*
* MSDN ref:
* http://msdn.microsoft.com/library/en-us/vclib/html/_crt_locale.asp
*
* It appears that we only need to do this on interpreter startup, and
* subsequent calls to the interpreter don't mess with the locale
* settings.
*
Abandon the use of Perl's Safe.pm to enforce restrictions in plperl, as it is fundamentally insecure. Instead apply an opmask to the whole interpreter that imposes restrictions on unsafe operations. These restrictions are much harder to subvert than is Safe.pm, since there is no container to be broken out of. Backported to release 7.4. In releases 7.4, 8.0 and 8.1 this also includes the necessary backporting of the two interpreters model for plperl and plperlu adopted in release 8.2. In versions 8.0 and up, the use of Perl's POSIX module to undo its locale mangling on Windows has become insecure with these changes, so it is replaced by our own routine, which is also faster. Nice side effects of the changes include that it is now possible to use perl's "strict" pragma in a natural way in plperl, and that perl's $a and $b variables now work as expected in sort routines, and that function compilation is significantly faster. Tim Bunce and Andrew Dunstan, with reviews from Alex Hunsaker and Alexey Klyukin. Security: CVE-2010-1169
2010-05-13 18:39:43 +02:00
* We restore them using setlocale_perl(), defined below, so that Perl
Undo perl's nasty locale setting on Windows. Since we can't do that as elsewhere by setting the environment appropriately, we make perl do it right after interpreter startup by calling its POSIX::setlocale().
2006-01-28 17:20:31 +01:00
* doesn't have a different idea of the locale from Postgres.
*
*/
char *loc;
char *save_collate,
*save_ctype,
*save_monetary,
*save_numeric,
*save_time;
loc = setlocale(LC_COLLATE, NULL);
save_collate = loc ? pstrdup(loc) : NULL;
loc = setlocale(LC_CTYPE, NULL);
save_ctype = loc ? pstrdup(loc) : NULL;
loc = setlocale(LC_MONETARY, NULL);
save_monetary = loc ? pstrdup(loc) : NULL;
loc = setlocale(LC_NUMERIC, NULL);
save_numeric = loc ? pstrdup(loc) : NULL;
loc = setlocale(LC_TIME, NULL);
save_time = loc ? pstrdup(loc) : NULL;
Abandon the use of Perl's Safe.pm to enforce restrictions in plperl, as it is fundamentally insecure. Instead apply an opmask to the whole interpreter that imposes restrictions on unsafe operations. These restrictions are much harder to subvert than is Safe.pm, since there is no container to be broken out of. Backported to release 7.4. In releases 7.4, 8.0 and 8.1 this also includes the necessary backporting of the two interpreters model for plperl and plperlu adopted in release 8.2. In versions 8.0 and up, the use of Perl's POSIX module to undo its locale mangling on Windows has become insecure with these changes, so it is replaced by our own routine, which is also faster. Nice side effects of the changes include that it is now possible to use perl's "strict" pragma in a natural way in plperl, and that perl's $a and $b variables now work as expected in sort routines, and that function compilation is significantly faster. Tim Bunce and Andrew Dunstan, with reviews from Alex Hunsaker and Alexey Klyukin. Security: CVE-2010-1169
2010-05-13 18:39:43 +02:00
#define PLPERL_RESTORE_LOCALE(name, saved) \
STMT_START { \
if (saved != NULL) { setlocale_perl(name, saved); pfree(saved); } \
} STMT_END
pgindent run on plperl.c
2011-02-17 20:40:13 +01:00
#endif /* WIN32 */
Undo perl's nasty locale setting on Windows. Since we can't do that as elsewhere by setting the environment appropriately, we make perl do it right after interpreter startup by calling its POSIX::setlocale().
2006-01-28 17:20:31 +01:00
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
if (plperl_on_init && *plperl_on_init)
Add plperl.on_perl_init setting to provide for initializing the perl library on load. Also, handle END blocks in plperl. Database access is disallowed during both these operations, although it might be allowed in END blocks in future. Patch from Tim Bunce.
2010-01-30 02:46:57 +01:00
{
embedding[nargs++] = "-e";
Add plperl.on_plperl_init and plperl.on_plperlu_init settings for language-specific startup. Rename recently added plperl.on_perl_init to plperl.on_init. Also, code cleanup for utf8 hack. Patch from Tim Bunce, reviewed by Alex Hunsaker.
2010-02-12 20:35:25 +01:00
embedding[nargs++] = plperl_on_init;
Add plperl.on_perl_init setting to provide for initializing the perl library on load. Also, handle END blocks in plperl. Database access is disallowed during both these operations, although it might be allowed in END blocks in future. Patch from Tim Bunce.
2010-01-30 02:46:57 +01:00
}
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
/*
Adjust recent PERL_SYS_INIT3 call to avoid platforms where it might fail, and to remove compilation warning. Backpatch the release 7.4
2009-06-05 22:32:00 +02:00
* The perl API docs state that PERL_SYS_INIT3 should be called before
pgindent run on plperl.c
2011-02-17 20:40:13 +01:00
* allocating interpreters. Unfortunately, on some platforms this fails in
* the Perl_do_taint() routine, which is called when the platform is using
* the system's malloc() instead of perl's own. Other platforms, notably
* Windows, fail if PERL_SYS_INIT3 is not called. So we call it if it's
* available, unless perl is using the system malloc(), which is true when
* MYMALLOC is set.
Adjust recent PERL_SYS_INIT3 call to avoid platforms where it might fail, and to remove compilation warning. Backpatch the release 7.4
2009-06-05 22:32:00 +02:00
*/
#if defined(PERL_SYS_INIT3) && !defined(MYMALLOC)
Move variable declaration to avoid 'unused variable' warning when the ifdef doesn't trigger. Not worth back-patching. Per buildfarm reports.
2009-06-06 05:45:36 +02:00
{
Force strings passed to and from plperl to be in UTF8 encoding. String are converted to UTF8 on the way into perl and to the database encoding on the way back. This avoids a number of observed anomalies, and ensures Perl a consistent view of the world. Some minor code cleanups are also accomplished. Alex Hunsaker, reviewed by Andy Colson.
2011-02-06 23:29:26 +01:00
static int perl_sys_init_done;
Move variable declaration to avoid 'unused variable' warning when the ifdef doesn't trigger. Not worth back-patching. Per buildfarm reports.
2009-06-06 05:45:36 +02:00
Force strings passed to and from plperl to be in UTF8 encoding. String are converted to UTF8 on the way into perl and to the database encoding on the way back. This avoids a number of observed anomalies, and ensures Perl a consistent view of the world. Some minor code cleanups are also accomplished. Alex Hunsaker, reviewed by Andy Colson.
2011-02-06 23:29:26 +01:00
/* only call this the first time through, as per perlembed man page */
if (!perl_sys_init_done)
{
char *dummy_env[1] = {NULL};
PERL_SYS_INIT3(&nargs, (char ***) &embedding, (char ***) &dummy_env);
Restore SIGFPE handler after initializing PL/Perl. Perl, for some unaccountable reason, believes it's a good idea to reset SIGFPE handling to SIG_IGN. Which wouldn't be a good idea even if it worked; but on some platforms (Linux at least) it doesn't work at all, instead resulting in forced process termination if the signal occurs. Given the lack of other complaints, it seems safe to assume that Perl never actually provokes SIGFPE and so there is no value in the setting anyway. Hence, reset it to our normal handler after initializing Perl. Report, analysis and patch by Andres Freund.
2012-09-05 22:43:37 +02:00
/*
* For unclear reasons, PERL_SYS_INIT3 sets the SIGFPE handler to
* SIG_IGN. Aside from being extremely unfriendly behavior for a
* library, this is dumb on the grounds that the results of a
* SIGFPE in this state are undefined according to POSIX, and in
* fact you get a forced process kill at least on Linux. Hence,
* restore the SIGFPE handler to the backend's standard setting.
* (See Perl bug 114574 for more information.)
*/
pqsignal(SIGFPE, FloatExceptionHandler);
Force strings passed to and from plperl to be in UTF8 encoding. String are converted to UTF8 on the way into perl and to the database encoding on the way back. This avoids a number of observed anomalies, and ensures Perl a consistent view of the world. Some minor code cleanups are also accomplished. Alex Hunsaker, reviewed by Andy Colson.
2011-02-06 23:29:26 +01:00
perl_sys_init_done = 1;
/* quiet warning if PERL_SYS_INIT3 doesn't use the third argument */
dummy_env[0] = NULL;
}
Move variable declaration to avoid 'unused variable' warning when the ifdef doesn't trigger. Not worth back-patching. Per buildfarm reports.
2009-06-06 05:45:36 +02:00
}
Initialise perl library as documented in perl API. Backpatch to release 7.4.
2009-06-04 17:59:55 +02:00
#endif
Tidy up and refactor plperl.c. - Changed MULTIPLICITY check from runtime to compiletime. No loads the large Config module. - Changed plperl_init_interp() to return new interp and not alter the global interp_state - Moved plperl_safe_init() call into check_interp(). - Removed plperl_safe_init_done state variable as interp_state now covers that role. - Changed plperl_create_sub() to take a plperl_proc_desc argument. - Simplified return value handling in plperl_create_sub. - Changed perl.com link in the docs to perl.org and tweaked wording to clarify that require, not use, is what's blocked. - Moved perl code in large multi-line C string literal macros out to plc_*.pl files. - Added a test2macro.pl utility to convert the plc_*.pl files to macros in a perlchunks.h file which is #included - Simplifed plperl_safe_init() slightly - Optimized pg_verifymbstr calls to avoid unneeded strlen()s. Patch from Tim Bunce, with minor editing from me.
2010-01-09 03:40:50 +01:00
plperl = perl_alloc();
if (!plperl)
Update plperl to use ereport() not elog() for user-facing messages, so that they will be translatable. Give messages some semblance of conformance to the style guide.
2004-11-29 21:11:06 +01:00
elog(ERROR, "could not allocate Perl interpreter");
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
Tidy up and refactor plperl.c. - Changed MULTIPLICITY check from runtime to compiletime. No loads the large Config module. - Changed plperl_init_interp() to return new interp and not alter the global interp_state - Moved plperl_safe_init() call into check_interp(). - Removed plperl_safe_init_done state variable as interp_state now covers that role. - Changed plperl_create_sub() to take a plperl_proc_desc argument. - Simplified return value handling in plperl_create_sub. - Changed perl.com link in the docs to perl.org and tweaked wording to clarify that require, not use, is what's blocked. - Moved perl code in large multi-line C string literal macros out to plc_*.pl files. - Added a test2macro.pl utility to convert the plc_*.pl files to macros in a perlchunks.h file which is #included - Simplifed plperl_safe_init() slightly - Optimized pg_verifymbstr calls to avoid unneeded strlen()s. Patch from Tim Bunce, with minor editing from me.
2010-01-09 03:40:50 +01:00
PERL_SET_CONTEXT(plperl);
perl_construct(plperl);
Various small improvements and cleanups for PL/Perl. - Allow (ineffective) use of 'require' in plperl If the required module is not already loaded then it dies. So "use strict;" now works in plperl. - Pre-load the feature module if perl >= 5.10. So "use feature :5.10;" now works in plperl. - Stored procedure subs are now given names. The names are not visible in ordinary use, but they make tools like Devel::NYTProf and Devel::Cover much more useful. - Simplified and generalized the subroutine creation code. Now one code path for generating sub source code, not four. Can generate multiple 'use' statements with specific imports (which handles plperl.use_strict currently and can easily be extended to handle a plperl.use_feature=':5.12' in future). - Disallows use of Safe version 2.20 which is broken for PL/Perl. http://rt.perl.org/rt3/Ticket/Display.html?id=72068 - Assorted minor optimizations by pre-growing data structures. Patch from Tim Bunce, reviewed by Alex Hunsaker.
2010-01-27 00:11:56 +01:00
/*
PL/Perl portability fix: avoid including XSUB.h in plperl.c. In Perl builds that define PERL_IMPLICIT_SYS, XSUB.h defines macros that replace a whole lot of basic libc functions with Perl functions. We can't tolerate that in plperl.c; it breaks at least PG_TRY and probably other stuff. The core idea of this patch is to include XSUB.h only in the .xs files where it's really needed, and to move any code broken by PERL_IMPLICIT_SYS out of the .xs files and into plperl.c. The reason this hasn't been a problem before is that our build techniques did not result in PERL_IMPLICIT_SYS appearing as a #define in PL/Perl, even on some platforms where Perl thinks it is defined. That's about to change in order to fix a nasty portability issue, so we need this work to make the code safe for that. Rather unaccountably, the Perl people chose XSUB.h as the place to provide the versions of the aTHX/aTHX_ macros that are needed by code that's not explicitly aware of the MULTIPLICITY API conventions. Hence, just removing XSUB.h from plperl.c fails miserably. But we can work around that by defining PERL_NO_GET_CONTEXT (which would make the relevant stanza of XSUB.h a no-op anyway). As explained in perlguts.pod, that means we need to add a "dTHX" macro call in every C function that calls a Perl API function. In most of them we just add this at the top; but since the macro fetches the current Perl interpreter pointer, more care is needed in functions that switch the active interpreter. Lack of the macro is easily recognized since it results in bleats about "my_perl" not being defined. (A nice side benefit of this is that it significantly reduces the number of fetches of the current interpreter pointer. On my machine, plperl.so gets more than 10% smaller, and there's probably some performance win too. We could reduce the number of fetches still more by decorating the code with pTHX_/aTHX_ macros to pass the interpreter pointer around, as explained by perlguts.pod; but that's a task for another day.) Formatting note: pgindent seems happy to treat "dTHX;" as a declaration so long as it's the first thing after the left brace, as we'd already observed with respect to the similar macro "dSP;". If you try to put it later in a set of declarations, pgindent puts ugly extra space around it. Having removed XSUB.h from plperl.c, we need only move the support functions for spi_return_next and util_elog (both of which use PG_TRY) out of the .xs files and into plperl.c. This seems sufficient to avoid the known problems caused by PERL_IMPLICIT_SYS, although we could move more code if additional issues emerge. This will need to be back-patched, but first let's see what the buildfarm makes of it. Patch by me, with some help from Ashutosh Sharma Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
2017-07-28 18:25:43 +02:00
* Run END blocks in perl_destruct instead of perl_run. Note that dTHX
* loads up a pointer to the current interpreter, so we have to postpone
* it to here rather than put it at the function head.
Various small improvements and cleanups for PL/Perl. - Allow (ineffective) use of 'require' in plperl If the required module is not already loaded then it dies. So "use strict;" now works in plperl. - Pre-load the feature module if perl >= 5.10. So "use feature :5.10;" now works in plperl. - Stored procedure subs are now given names. The names are not visible in ordinary use, but they make tools like Devel::NYTProf and Devel::Cover much more useful. - Simplified and generalized the subroutine creation code. Now one code path for generating sub source code, not four. Can generate multiple 'use' statements with specific imports (which handles plperl.use_strict currently and can easily be extended to handle a plperl.use_feature=':5.12' in future). - Disallows use of Safe version 2.20 which is broken for PL/Perl. http://rt.perl.org/rt3/Ticket/Display.html?id=72068 - Assorted minor optimizations by pre-growing data structures. Patch from Tim Bunce, reviewed by Alex Hunsaker.
2010-01-27 00:11:56 +01:00
*/
Abandon the use of Perl's Safe.pm to enforce restrictions in plperl, as it is fundamentally insecure. Instead apply an opmask to the whole interpreter that imposes restrictions on unsafe operations. These restrictions are much harder to subvert than is Safe.pm, since there is no container to be broken out of. Backported to release 7.4. In releases 7.4, 8.0 and 8.1 this also includes the necessary backporting of the two interpreters model for plperl and plperlu adopted in release 8.2. In versions 8.0 and up, the use of Perl's POSIX module to undo its locale mangling on Windows has become insecure with these changes, so it is replaced by our own routine, which is also faster. Nice side effects of the changes include that it is now possible to use perl's "strict" pragma in a natural way in plperl, and that perl's $a and $b variables now work as expected in sort routines, and that function compilation is significantly faster. Tim Bunce and Andrew Dunstan, with reviews from Alex Hunsaker and Alexey Klyukin. Security: CVE-2010-1169
2010-05-13 18:39:43 +02:00
{
PL/Perl portability fix: avoid including XSUB.h in plperl.c. In Perl builds that define PERL_IMPLICIT_SYS, XSUB.h defines macros that replace a whole lot of basic libc functions with Perl functions. We can't tolerate that in plperl.c; it breaks at least PG_TRY and probably other stuff. The core idea of this patch is to include XSUB.h only in the .xs files where it's really needed, and to move any code broken by PERL_IMPLICIT_SYS out of the .xs files and into plperl.c. The reason this hasn't been a problem before is that our build techniques did not result in PERL_IMPLICIT_SYS appearing as a #define in PL/Perl, even on some platforms where Perl thinks it is defined. That's about to change in order to fix a nasty portability issue, so we need this work to make the code safe for that. Rather unaccountably, the Perl people chose XSUB.h as the place to provide the versions of the aTHX/aTHX_ macros that are needed by code that's not explicitly aware of the MULTIPLICITY API conventions. Hence, just removing XSUB.h from plperl.c fails miserably. But we can work around that by defining PERL_NO_GET_CONTEXT (which would make the relevant stanza of XSUB.h a no-op anyway). As explained in perlguts.pod, that means we need to add a "dTHX" macro call in every C function that calls a Perl API function. In most of them we just add this at the top; but since the macro fetches the current Perl interpreter pointer, more care is needed in functions that switch the active interpreter. Lack of the macro is easily recognized since it results in bleats about "my_perl" not being defined. (A nice side benefit of this is that it significantly reduces the number of fetches of the current interpreter pointer. On my machine, plperl.so gets more than 10% smaller, and there's probably some performance win too. We could reduce the number of fetches still more by decorating the code with pTHX_/aTHX_ macros to pass the interpreter pointer around, as explained by perlguts.pod; but that's a task for another day.) Formatting note: pgindent seems happy to treat "dTHX;" as a declaration so long as it's the first thing after the left brace, as we'd already observed with respect to the similar macro "dSP;". If you try to put it later in a set of declarations, pgindent puts ugly extra space around it. Having removed XSUB.h from plperl.c, we need only move the support functions for spi_return_next and util_elog (both of which use PG_TRY) out of the .xs files and into plperl.c. This seems sufficient to avoid the known problems caused by PERL_IMPLICIT_SYS, although we could move more code if additional issues emerge. This will need to be back-patched, but first let's see what the buildfarm makes of it. Patch by me, with some help from Ashutosh Sharma Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
2017-07-28 18:25:43 +02:00
dTHX;
PL_exit_flags |= PERL_EXIT_DESTRUCT_END;
/*
* Record the original function for the 'require' and 'dofile'
* opcodes. (They share the same implementation.) Ensure it's used
* for new interpreters.
*/
if (!pp_require_orig)
pp_require_orig = PL_ppaddr[OP_REQUIRE];
else
{
PL_ppaddr[OP_REQUIRE] = pp_require_orig;
PL_ppaddr[OP_DOFILE] = pp_require_orig;
}
Abandon the use of Perl's Safe.pm to enforce restrictions in plperl, as it is fundamentally insecure. Instead apply an opmask to the whole interpreter that imposes restrictions on unsafe operations. These restrictions are much harder to subvert than is Safe.pm, since there is no container to be broken out of. Backported to release 7.4. In releases 7.4, 8.0 and 8.1 this also includes the necessary backporting of the two interpreters model for plperl and plperlu adopted in release 8.2. In versions 8.0 and up, the use of Perl's POSIX module to undo its locale mangling on Windows has become insecure with these changes, so it is replaced by our own routine, which is also faster. Nice side effects of the changes include that it is now possible to use perl's "strict" pragma in a natural way in plperl, and that perl's $a and $b variables now work as expected in sort routines, and that function compilation is significantly faster. Tim Bunce and Andrew Dunstan, with reviews from Alex Hunsaker and Alexey Klyukin. Security: CVE-2010-1169
2010-05-13 18:39:43 +02:00
#ifdef PLPERL_ENABLE_OPMASK_EARLY
pgindent run for 9.0, second run
2010-07-06 21:19:02 +02:00
PL/Perl portability fix: avoid including XSUB.h in plperl.c. In Perl builds that define PERL_IMPLICIT_SYS, XSUB.h defines macros that replace a whole lot of basic libc functions with Perl functions. We can't tolerate that in plperl.c; it breaks at least PG_TRY and probably other stuff. The core idea of this patch is to include XSUB.h only in the .xs files where it's really needed, and to move any code broken by PERL_IMPLICIT_SYS out of the .xs files and into plperl.c. The reason this hasn't been a problem before is that our build techniques did not result in PERL_IMPLICIT_SYS appearing as a #define in PL/Perl, even on some platforms where Perl thinks it is defined. That's about to change in order to fix a nasty portability issue, so we need this work to make the code safe for that. Rather unaccountably, the Perl people chose XSUB.h as the place to provide the versions of the aTHX/aTHX_ macros that are needed by code that's not explicitly aware of the MULTIPLICITY API conventions. Hence, just removing XSUB.h from plperl.c fails miserably. But we can work around that by defining PERL_NO_GET_CONTEXT (which would make the relevant stanza of XSUB.h a no-op anyway). As explained in perlguts.pod, that means we need to add a "dTHX" macro call in every C function that calls a Perl API function. In most of them we just add this at the top; but since the macro fetches the current Perl interpreter pointer, more care is needed in functions that switch the active interpreter. Lack of the macro is easily recognized since it results in bleats about "my_perl" not being defined. (A nice side benefit of this is that it significantly reduces the number of fetches of the current interpreter pointer. On my machine, plperl.so gets more than 10% smaller, and there's probably some performance win too. We could reduce the number of fetches still more by decorating the code with pTHX_/aTHX_ macros to pass the interpreter pointer around, as explained by perlguts.pod; but that's a task for another day.) Formatting note: pgindent seems happy to treat "dTHX;" as a declaration so long as it's the first thing after the left brace, as we'd already observed with respect to the similar macro "dSP;". If you try to put it later in a set of declarations, pgindent puts ugly extra space around it. Having removed XSUB.h from plperl.c, we need only move the support functions for spi_return_next and util_elog (both of which use PG_TRY) out of the .xs files and into plperl.c. This seems sufficient to avoid the known problems caused by PERL_IMPLICIT_SYS, although we could move more code if additional issues emerge. This will need to be back-patched, but first let's see what the buildfarm makes of it. Patch by me, with some help from Ashutosh Sharma Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
2017-07-28 18:25:43 +02:00
/*
* For regression testing to prove that the PLC_PERLBOOT and
* PLC_TRUSTED code doesn't even compile any unsafe ops. In future
* there may be a valid need for them to do so, in which case this
* could be softened (perhaps moved to plperl_trusted_init()) or
* removed.
*/
PL_op_mask = plperl_opmask;
Abandon the use of Perl's Safe.pm to enforce restrictions in plperl, as it is fundamentally insecure. Instead apply an opmask to the whole interpreter that imposes restrictions on unsafe operations. These restrictions are much harder to subvert than is Safe.pm, since there is no container to be broken out of. Backported to release 7.4. In releases 7.4, 8.0 and 8.1 this also includes the necessary backporting of the two interpreters model for plperl and plperlu adopted in release 8.2. In versions 8.0 and up, the use of Perl's POSIX module to undo its locale mangling on Windows has become insecure with these changes, so it is replaced by our own routine, which is also faster. Nice side effects of the changes include that it is now possible to use perl's "strict" pragma in a natural way in plperl, and that perl's $a and $b variables now work as expected in sort routines, and that function compilation is significantly faster. Tim Bunce and Andrew Dunstan, with reviews from Alex Hunsaker and Alexey Klyukin. Security: CVE-2010-1169
2010-05-13 18:39:43 +02:00
#endif
Various small improvements and cleanups for PL/Perl. - Allow (ineffective) use of 'require' in plperl If the required module is not already loaded then it dies. So "use strict;" now works in plperl. - Pre-load the feature module if perl >= 5.10. So "use feature :5.10;" now works in plperl. - Stored procedure subs are now given names. The names are not visible in ordinary use, but they make tools like Devel::NYTProf and Devel::Cover much more useful. - Simplified and generalized the subroutine creation code. Now one code path for generating sub source code, not four. Can generate multiple 'use' statements with specific imports (which handles plperl.use_strict currently and can easily be extended to handle a plperl.use_feature=':5.12' in future). - Disallows use of Safe version 2.20 which is broken for PL/Perl. http://rt.perl.org/rt3/Ticket/Display.html?id=72068 - Assorted minor optimizations by pre-growing data structures. Patch from Tim Bunce, reviewed by Alex Hunsaker.
2010-01-27 00:11:56 +01:00
PL/Perl portability fix: avoid including XSUB.h in plperl.c. In Perl builds that define PERL_IMPLICIT_SYS, XSUB.h defines macros that replace a whole lot of basic libc functions with Perl functions. We can't tolerate that in plperl.c; it breaks at least PG_TRY and probably other stuff. The core idea of this patch is to include XSUB.h only in the .xs files where it's really needed, and to move any code broken by PERL_IMPLICIT_SYS out of the .xs files and into plperl.c. The reason this hasn't been a problem before is that our build techniques did not result in PERL_IMPLICIT_SYS appearing as a #define in PL/Perl, even on some platforms where Perl thinks it is defined. That's about to change in order to fix a nasty portability issue, so we need this work to make the code safe for that. Rather unaccountably, the Perl people chose XSUB.h as the place to provide the versions of the aTHX/aTHX_ macros that are needed by code that's not explicitly aware of the MULTIPLICITY API conventions. Hence, just removing XSUB.h from plperl.c fails miserably. But we can work around that by defining PERL_NO_GET_CONTEXT (which would make the relevant stanza of XSUB.h a no-op anyway). As explained in perlguts.pod, that means we need to add a "dTHX" macro call in every C function that calls a Perl API function. In most of them we just add this at the top; but since the macro fetches the current Perl interpreter pointer, more care is needed in functions that switch the active interpreter. Lack of the macro is easily recognized since it results in bleats about "my_perl" not being defined. (A nice side benefit of this is that it significantly reduces the number of fetches of the current interpreter pointer. On my machine, plperl.so gets more than 10% smaller, and there's probably some performance win too. We could reduce the number of fetches still more by decorating the code with pTHX_/aTHX_ macros to pass the interpreter pointer around, as explained by perlguts.pod; but that's a task for another day.) Formatting note: pgindent seems happy to treat "dTHX;" as a declaration so long as it's the first thing after the left brace, as we'd already observed with respect to the similar macro "dSP;". If you try to put it later in a set of declarations, pgindent puts ugly extra space around it. Having removed XSUB.h from plperl.c, we need only move the support functions for spi_return_next and util_elog (both of which use PG_TRY) out of the .xs files and into plperl.c. This seems sufficient to avoid the known problems caused by PERL_IMPLICIT_SYS, although we could move more code if additional issues emerge. This will need to be back-patched, but first let's see what the buildfarm makes of it. Patch by me, with some help from Ashutosh Sharma Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
2017-07-28 18:25:43 +02:00
if (perl_parse(plperl, plperl_init_shared_libs,
nargs, embedding, NULL) != 0)
ereport(ERROR,
(errcode(ERRCODE_EXTERNAL_ROUTINE_EXCEPTION),
errmsg("%s", strip_trailing_ws(sv2cstr(ERRSV))),
errcontext("while parsing Perl initialization")));
Add plperl.on_perl_init setting to provide for initializing the perl library on load. Also, handle END blocks in plperl. Database access is disallowed during both these operations, although it might be allowed in END blocks in future. Patch from Tim Bunce.
2010-01-30 02:46:57 +01:00
PL/Perl portability fix: avoid including XSUB.h in plperl.c. In Perl builds that define PERL_IMPLICIT_SYS, XSUB.h defines macros that replace a whole lot of basic libc functions with Perl functions. We can't tolerate that in plperl.c; it breaks at least PG_TRY and probably other stuff. The core idea of this patch is to include XSUB.h only in the .xs files where it's really needed, and to move any code broken by PERL_IMPLICIT_SYS out of the .xs files and into plperl.c. The reason this hasn't been a problem before is that our build techniques did not result in PERL_IMPLICIT_SYS appearing as a #define in PL/Perl, even on some platforms where Perl thinks it is defined. That's about to change in order to fix a nasty portability issue, so we need this work to make the code safe for that. Rather unaccountably, the Perl people chose XSUB.h as the place to provide the versions of the aTHX/aTHX_ macros that are needed by code that's not explicitly aware of the MULTIPLICITY API conventions. Hence, just removing XSUB.h from plperl.c fails miserably. But we can work around that by defining PERL_NO_GET_CONTEXT (which would make the relevant stanza of XSUB.h a no-op anyway). As explained in perlguts.pod, that means we need to add a "dTHX" macro call in every C function that calls a Perl API function. In most of them we just add this at the top; but since the macro fetches the current Perl interpreter pointer, more care is needed in functions that switch the active interpreter. Lack of the macro is easily recognized since it results in bleats about "my_perl" not being defined. (A nice side benefit of this is that it significantly reduces the number of fetches of the current interpreter pointer. On my machine, plperl.so gets more than 10% smaller, and there's probably some performance win too. We could reduce the number of fetches still more by decorating the code with pTHX_/aTHX_ macros to pass the interpreter pointer around, as explained by perlguts.pod; but that's a task for another day.) Formatting note: pgindent seems happy to treat "dTHX;" as a declaration so long as it's the first thing after the left brace, as we'd already observed with respect to the similar macro "dSP;". If you try to put it later in a set of declarations, pgindent puts ugly extra space around it. Having removed XSUB.h from plperl.c, we need only move the support functions for spi_return_next and util_elog (both of which use PG_TRY) out of the .xs files and into plperl.c. This seems sufficient to avoid the known problems caused by PERL_IMPLICIT_SYS, although we could move more code if additional issues emerge. This will need to be back-patched, but first let's see what the buildfarm makes of it. Patch by me, with some help from Ashutosh Sharma Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
2017-07-28 18:25:43 +02:00
if (perl_run(plperl) != 0)
ereport(ERROR,
(errcode(ERRCODE_EXTERNAL_ROUTINE_EXCEPTION),
errmsg("%s", strip_trailing_ws(sv2cstr(ERRSV))),
errcontext("while running Perl initialization")));
Undo perl's nasty locale setting on Windows. Since we can't do that as elsewhere by setting the environment appropriately, we make perl do it right after interpreter startup by calling its POSIX::setlocale().
2006-01-28 17:20:31 +01:00
Abandon the use of Perl's Safe.pm to enforce restrictions in plperl, as it is fundamentally insecure. Instead apply an opmask to the whole interpreter that imposes restrictions on unsafe operations. These restrictions are much harder to subvert than is Safe.pm, since there is no container to be broken out of. Backported to release 7.4. In releases 7.4, 8.0 and 8.1 this also includes the necessary backporting of the two interpreters model for plperl and plperlu adopted in release 8.2. In versions 8.0 and up, the use of Perl's POSIX module to undo its locale mangling on Windows has become insecure with these changes, so it is replaced by our own routine, which is also faster. Nice side effects of the changes include that it is now possible to use perl's "strict" pragma in a natural way in plperl, and that perl's $a and $b variables now work as expected in sort routines, and that function compilation is significantly faster. Tim Bunce and Andrew Dunstan, with reviews from Alex Hunsaker and Alexey Klyukin. Security: CVE-2010-1169
2010-05-13 18:39:43 +02:00
#ifdef PLPERL_RESTORE_LOCALE
PL/Perl portability fix: avoid including XSUB.h in plperl.c. In Perl builds that define PERL_IMPLICIT_SYS, XSUB.h defines macros that replace a whole lot of basic libc functions with Perl functions. We can't tolerate that in plperl.c; it breaks at least PG_TRY and probably other stuff. The core idea of this patch is to include XSUB.h only in the .xs files where it's really needed, and to move any code broken by PERL_IMPLICIT_SYS out of the .xs files and into plperl.c. The reason this hasn't been a problem before is that our build techniques did not result in PERL_IMPLICIT_SYS appearing as a #define in PL/Perl, even on some platforms where Perl thinks it is defined. That's about to change in order to fix a nasty portability issue, so we need this work to make the code safe for that. Rather unaccountably, the Perl people chose XSUB.h as the place to provide the versions of the aTHX/aTHX_ macros that are needed by code that's not explicitly aware of the MULTIPLICITY API conventions. Hence, just removing XSUB.h from plperl.c fails miserably. But we can work around that by defining PERL_NO_GET_CONTEXT (which would make the relevant stanza of XSUB.h a no-op anyway). As explained in perlguts.pod, that means we need to add a "dTHX" macro call in every C function that calls a Perl API function. In most of them we just add this at the top; but since the macro fetches the current Perl interpreter pointer, more care is needed in functions that switch the active interpreter. Lack of the macro is easily recognized since it results in bleats about "my_perl" not being defined. (A nice side benefit of this is that it significantly reduces the number of fetches of the current interpreter pointer. On my machine, plperl.so gets more than 10% smaller, and there's probably some performance win too. We could reduce the number of fetches still more by decorating the code with pTHX_/aTHX_ macros to pass the interpreter pointer around, as explained by perlguts.pod; but that's a task for another day.) Formatting note: pgindent seems happy to treat "dTHX;" as a declaration so long as it's the first thing after the left brace, as we'd already observed with respect to the similar macro "dSP;". If you try to put it later in a set of declarations, pgindent puts ugly extra space around it. Having removed XSUB.h from plperl.c, we need only move the support functions for spi_return_next and util_elog (both of which use PG_TRY) out of the .xs files and into plperl.c. This seems sufficient to avoid the known problems caused by PERL_IMPLICIT_SYS, although we could move more code if additional issues emerge. This will need to be back-patched, but first let's see what the buildfarm makes of it. Patch by me, with some help from Ashutosh Sharma Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
2017-07-28 18:25:43 +02:00
PLPERL_RESTORE_LOCALE(LC_COLLATE, save_collate);
PLPERL_RESTORE_LOCALE(LC_CTYPE, save_ctype);
PLPERL_RESTORE_LOCALE(LC_MONETARY, save_monetary);
PLPERL_RESTORE_LOCALE(LC_NUMERIC, save_numeric);
PLPERL_RESTORE_LOCALE(LC_TIME, save_time);
Undo perl's nasty locale setting on Windows. Since we can't do that as elsewhere by setting the environment appropriately, we make perl do it right after interpreter startup by calling its POSIX::setlocale().
2006-01-28 17:20:31 +01:00
#endif
PL/Perl portability fix: avoid including XSUB.h in plperl.c. In Perl builds that define PERL_IMPLICIT_SYS, XSUB.h defines macros that replace a whole lot of basic libc functions with Perl functions. We can't tolerate that in plperl.c; it breaks at least PG_TRY and probably other stuff. The core idea of this patch is to include XSUB.h only in the .xs files where it's really needed, and to move any code broken by PERL_IMPLICIT_SYS out of the .xs files and into plperl.c. The reason this hasn't been a problem before is that our build techniques did not result in PERL_IMPLICIT_SYS appearing as a #define in PL/Perl, even on some platforms where Perl thinks it is defined. That's about to change in order to fix a nasty portability issue, so we need this work to make the code safe for that. Rather unaccountably, the Perl people chose XSUB.h as the place to provide the versions of the aTHX/aTHX_ macros that are needed by code that's not explicitly aware of the MULTIPLICITY API conventions. Hence, just removing XSUB.h from plperl.c fails miserably. But we can work around that by defining PERL_NO_GET_CONTEXT (which would make the relevant stanza of XSUB.h a no-op anyway). As explained in perlguts.pod, that means we need to add a "dTHX" macro call in every C function that calls a Perl API function. In most of them we just add this at the top; but since the macro fetches the current Perl interpreter pointer, more care is needed in functions that switch the active interpreter. Lack of the macro is easily recognized since it results in bleats about "my_perl" not being defined. (A nice side benefit of this is that it significantly reduces the number of fetches of the current interpreter pointer. On my machine, plperl.so gets more than 10% smaller, and there's probably some performance win too. We could reduce the number of fetches still more by decorating the code with pTHX_/aTHX_ macros to pass the interpreter pointer around, as explained by perlguts.pod; but that's a task for another day.) Formatting note: pgindent seems happy to treat "dTHX;" as a declaration so long as it's the first thing after the left brace, as we'd already observed with respect to the similar macro "dSP;". If you try to put it later in a set of declarations, pgindent puts ugly extra space around it. Having removed XSUB.h from plperl.c, we need only move the support functions for spi_return_next and util_elog (both of which use PG_TRY) out of the .xs files and into plperl.c. This seems sufficient to avoid the known problems caused by PERL_IMPLICIT_SYS, although we could move more code if additional issues emerge. This will need to be back-patched, but first let's see what the buildfarm makes of it. Patch by me, with some help from Ashutosh Sharma Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
2017-07-28 18:25:43 +02:00
}
Undo perl's nasty locale setting on Windows. Since we can't do that as elsewhere by setting the environment appropriately, we make perl do it right after interpreter startup by calling its POSIX::setlocale().
2006-01-28 17:20:31 +01:00
Tidy up and refactor plperl.c. - Changed MULTIPLICITY check from runtime to compiletime. No loads the large Config module. - Changed plperl_init_interp() to return new interp and not alter the global interp_state - Moved plperl_safe_init() call into check_interp(). - Removed plperl_safe_init_done state variable as interp_state now covers that role. - Changed plperl_create_sub() to take a plperl_proc_desc argument. - Simplified return value handling in plperl_create_sub. - Changed perl.com link in the docs to perl.org and tweaked wording to clarify that require, not use, is what's blocked. - Moved perl code in large multi-line C string literal macros out to plc_*.pl files. - Added a test2macro.pl utility to convert the plc_*.pl files to macros in a perlchunks.h file which is #included - Simplifed plperl_safe_init() slightly - Optimized pg_verifymbstr calls to avoid unneeded strlen()s. Patch from Tim Bunce, with minor editing from me.
2010-01-09 03:40:50 +01:00
return plperl;
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
}
The attached patch, which incorporates the previous one sent and currently unapplied regarding spi_internal.c, makes some additional fixes relating to return types, and also contains the fix for preventing the use of insecure versions of Safe.pm. There is one remaing return case that does not appear to work, namely return of a composite directly in a select, i.e. if foo returns some composite type, 'select * from foo()' works but 'select foo()' doesn't. We will either fix that or document it as a limitation. The function plperl_func_handler is a mess - I will try to get it cleaned up (and split up) in a subsequent patch, time permitting. Also, reiterating previous advice - this changes slightly the API for spi_exec_query - the returned object has either 2 or 3 members: 'status' (string) and 'proceesed' (int,- number of rows) and, if rows are returned, 'rows' (array of tuple hashes). Andrew Dunstan
2004-07-12 16:31:04 +02:00
Various small improvements and cleanups for PL/Perl. - Allow (ineffective) use of 'require' in plperl If the required module is not already loaded then it dies. So "use strict;" now works in plperl. - Pre-load the feature module if perl >= 5.10. So "use feature :5.10;" now works in plperl. - Stored procedure subs are now given names. The names are not visible in ordinary use, but they make tools like Devel::NYTProf and Devel::Cover much more useful. - Simplified and generalized the subroutine creation code. Now one code path for generating sub source code, not four. Can generate multiple 'use' statements with specific imports (which handles plperl.use_strict currently and can easily be extended to handle a plperl.use_feature=':5.12' in future). - Disallows use of Safe version 2.20 which is broken for PL/Perl. http://rt.perl.org/rt3/Ticket/Display.html?id=72068 - Assorted minor optimizations by pre-growing data structures. Patch from Tim Bunce, reviewed by Alex Hunsaker.
2010-01-27 00:11:56 +01:00
/*
* Our safe implementation of the require opcode.
* This is safe because it's completely unable to load any code.
* If the requested file/module has already been loaded it'll return true.
* If not, it'll die.
* So now "use Foo;" will work iff Foo has already been loaded.
*/
static OP *
pp_require_safe(pTHX)
{
dVAR;
dSP;
SV *sv,
**svp;
char *name;
STRLEN len;
sv = POPs;
name = SvPV(sv, len);
if (!(name && len > 0 && *name))
RETPUSHNO;
svp = hv_fetch(GvHVn(PL_incgv), name, len, 0);
if (svp && *svp != &PL_sv_undef)
RETPUSHYES;
DIE(aTHX_ "Unable to load %s into plperl", name);
pgindent run for release 9.3 This is the first run of the Perl-based pgindent script. Also update pgindent instructions.
2013-05-29 22:58:43 +02:00
Add comment why seemingly dead code is necessary
2012-07-16 21:08:04 +02:00
/*
* In most Perl versions, DIE() expands to a return statement, so the next
* line is not necessary. But in versions between but not including
* 5.11.1 and 5.13.3 it does not, so the next line is necessary to avoid a
* "control reaches end of non-void function" warning from gcc. Other
* compilers such as Solaris Studio will, however, issue a "statement not
* reached" warning instead.
*/
return NULL;
Various small improvements and cleanups for PL/Perl. - Allow (ineffective) use of 'require' in plperl If the required module is not already loaded then it dies. So "use strict;" now works in plperl. - Pre-load the feature module if perl >= 5.10. So "use feature :5.10;" now works in plperl. - Stored procedure subs are now given names. The names are not visible in ordinary use, but they make tools like Devel::NYTProf and Devel::Cover much more useful. - Simplified and generalized the subroutine creation code. Now one code path for generating sub source code, not four. Can generate multiple 'use' statements with specific imports (which handles plperl.use_strict currently and can easily be extended to handle a plperl.use_feature=':5.12' in future). - Disallows use of Safe version 2.20 which is broken for PL/Perl. http://rt.perl.org/rt3/Ticket/Display.html?id=72068 - Assorted minor optimizations by pre-growing data structures. Patch from Tim Bunce, reviewed by Alex Hunsaker.
2010-01-27 00:11:56 +01:00
}
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
/*
* Destroy one Perl interpreter ... actually we just run END blocks.
*
* Caller must have ensured this interpreter is the active one.
*/
Add plperl.on_perl_init setting to provide for initializing the perl library on load. Also, handle END blocks in plperl. Database access is disallowed during both these operations, although it might be allowed in END blocks in future. Patch from Tim Bunce.
2010-01-30 02:46:57 +01:00
static void
plperl_destroy_interp(PerlInterpreter **interp)
{
if (interp && *interp)
{
/*
* Only a very minimal destruction is performed: - just call END
* blocks.
*
* We could call perl_destruct() but we'd need to audit its actions
* very carefully and work-around any that impact us. (Calling
* sv_clean_objs() isn't an option because it's not part of perl's
* public API so isn't portably available.) Meanwhile END blocks can
* be used to perform manual cleanup.
*/
PL/Perl portability fix: avoid including XSUB.h in plperl.c. In Perl builds that define PERL_IMPLICIT_SYS, XSUB.h defines macros that replace a whole lot of basic libc functions with Perl functions. We can't tolerate that in plperl.c; it breaks at least PG_TRY and probably other stuff. The core idea of this patch is to include XSUB.h only in the .xs files where it's really needed, and to move any code broken by PERL_IMPLICIT_SYS out of the .xs files and into plperl.c. The reason this hasn't been a problem before is that our build techniques did not result in PERL_IMPLICIT_SYS appearing as a #define in PL/Perl, even on some platforms where Perl thinks it is defined. That's about to change in order to fix a nasty portability issue, so we need this work to make the code safe for that. Rather unaccountably, the Perl people chose XSUB.h as the place to provide the versions of the aTHX/aTHX_ macros that are needed by code that's not explicitly aware of the MULTIPLICITY API conventions. Hence, just removing XSUB.h from plperl.c fails miserably. But we can work around that by defining PERL_NO_GET_CONTEXT (which would make the relevant stanza of XSUB.h a no-op anyway). As explained in perlguts.pod, that means we need to add a "dTHX" macro call in every C function that calls a Perl API function. In most of them we just add this at the top; but since the macro fetches the current Perl interpreter pointer, more care is needed in functions that switch the active interpreter. Lack of the macro is easily recognized since it results in bleats about "my_perl" not being defined. (A nice side benefit of this is that it significantly reduces the number of fetches of the current interpreter pointer. On my machine, plperl.so gets more than 10% smaller, and there's probably some performance win too. We could reduce the number of fetches still more by decorating the code with pTHX_/aTHX_ macros to pass the interpreter pointer around, as explained by perlguts.pod; but that's a task for another day.) Formatting note: pgindent seems happy to treat "dTHX;" as a declaration so long as it's the first thing after the left brace, as we'd already observed with respect to the similar macro "dSP;". If you try to put it later in a set of declarations, pgindent puts ugly extra space around it. Having removed XSUB.h from plperl.c, we need only move the support functions for spi_return_next and util_elog (both of which use PG_TRY) out of the .xs files and into plperl.c. This seems sufficient to avoid the known problems caused by PERL_IMPLICIT_SYS, although we could move more code if additional issues emerge. This will need to be back-patched, but first let's see what the buildfarm makes of it. Patch by me, with some help from Ashutosh Sharma Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
2017-07-28 18:25:43 +02:00
dTHX;
Add plperl.on_perl_init setting to provide for initializing the perl library on load. Also, handle END blocks in plperl. Database access is disallowed during both these operations, although it might be allowed in END blocks in future. Patch from Tim Bunce.
2010-01-30 02:46:57 +01:00
/* Run END blocks - based on perl's perl_destruct() */
if (PL_exit_flags & PERL_EXIT_DESTRUCT_END)
{
dJMPENV;
int x = 0;
JMPENV_PUSH(x);
PERL_UNUSED_VAR(x);
if (PL_endav && !PL_minus_c)
call_list(PL_scopestack_ix, PL_endav);
JMPENV_POP;
}
LEAVE;
FREETMPS;
*interp = NULL;
}
}
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
/*
* Initialize the current Perl interpreter as a trusted interp
*/
The attached patch, which incorporates the previous one sent and currently unapplied regarding spi_internal.c, makes some additional fixes relating to return types, and also contains the fix for preventing the use of insecure versions of Safe.pm. There is one remaing return case that does not appear to work, namely return of a composite directly in a select, i.e. if foo returns some composite type, 'select * from foo()' works but 'select foo()' doesn't. We will either fix that or document it as a limitation. The function plperl_func_handler is a mess - I will try to get it cleaned up (and split up) in a subsequent patch, time permitting. Also, reiterating previous advice - this changes slightly the API for spi_exec_query - the returned object has either 2 or 3 members: 'status' (string) and 'proceesed' (int,- number of rows) and, if rows are returned, 'rows' (array of tuple hashes). Andrew Dunstan
2004-07-12 16:31:04 +02:00
static void
Add plperl.on_plperl_init and plperl.on_plperlu_init settings for language-specific startup. Rename recently added plperl.on_perl_init to plperl.on_init. Also, code cleanup for utf8 hack. Patch from Tim Bunce, reviewed by Alex Hunsaker.
2010-02-12 20:35:25 +01:00
plperl_trusted_init(void)
The attached patch, which incorporates the previous one sent and currently unapplied regarding spi_internal.c, makes some additional fixes relating to return types, and also contains the fix for preventing the use of insecure versions of Safe.pm. There is one remaing return case that does not appear to work, namely return of a composite directly in a select, i.e. if foo returns some composite type, 'select * from foo()' works but 'select foo()' doesn't. We will either fix that or document it as a limitation. The function plperl_func_handler is a mess - I will try to get it cleaned up (and split up) in a subsequent patch, time permitting. Also, reiterating previous advice - this changes slightly the API for spi_exec_query - the returned object has either 2 or 3 members: 'status' (string) and 'proceesed' (int,- number of rows) and, if rows are returned, 'rows' (array of tuple hashes). Andrew Dunstan
2004-07-12 16:31:04 +02:00
{
PL/Perl portability fix: avoid including XSUB.h in plperl.c. In Perl builds that define PERL_IMPLICIT_SYS, XSUB.h defines macros that replace a whole lot of basic libc functions with Perl functions. We can't tolerate that in plperl.c; it breaks at least PG_TRY and probably other stuff. The core idea of this patch is to include XSUB.h only in the .xs files where it's really needed, and to move any code broken by PERL_IMPLICIT_SYS out of the .xs files and into plperl.c. The reason this hasn't been a problem before is that our build techniques did not result in PERL_IMPLICIT_SYS appearing as a #define in PL/Perl, even on some platforms where Perl thinks it is defined. That's about to change in order to fix a nasty portability issue, so we need this work to make the code safe for that. Rather unaccountably, the Perl people chose XSUB.h as the place to provide the versions of the aTHX/aTHX_ macros that are needed by code that's not explicitly aware of the MULTIPLICITY API conventions. Hence, just removing XSUB.h from plperl.c fails miserably. But we can work around that by defining PERL_NO_GET_CONTEXT (which would make the relevant stanza of XSUB.h a no-op anyway). As explained in perlguts.pod, that means we need to add a "dTHX" macro call in every C function that calls a Perl API function. In most of them we just add this at the top; but since the macro fetches the current Perl interpreter pointer, more care is needed in functions that switch the active interpreter. Lack of the macro is easily recognized since it results in bleats about "my_perl" not being defined. (A nice side benefit of this is that it significantly reduces the number of fetches of the current interpreter pointer. On my machine, plperl.so gets more than 10% smaller, and there's probably some performance win too. We could reduce the number of fetches still more by decorating the code with pTHX_/aTHX_ macros to pass the interpreter pointer around, as explained by perlguts.pod; but that's a task for another day.) Formatting note: pgindent seems happy to treat "dTHX;" as a declaration so long as it's the first thing after the left brace, as we'd already observed with respect to the similar macro "dSP;". If you try to put it later in a set of declarations, pgindent puts ugly extra space around it. Having removed XSUB.h from plperl.c, we need only move the support functions for spi_return_next and util_elog (both of which use PG_TRY) out of the .xs files and into plperl.c. This seems sufficient to avoid the known problems caused by PERL_IMPLICIT_SYS, although we could move more code if additional issues emerge. This will need to be back-patched, but first let's see what the buildfarm makes of it. Patch by me, with some help from Ashutosh Sharma Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
2017-07-28 18:25:43 +02:00
dTHX;
Abandon the use of Perl's Safe.pm to enforce restrictions in plperl, as it is fundamentally insecure. Instead apply an opmask to the whole interpreter that imposes restrictions on unsafe operations. These restrictions are much harder to subvert than is Safe.pm, since there is no container to be broken out of. Backported to release 7.4. In releases 7.4, 8.0 and 8.1 this also includes the necessary backporting of the two interpreters model for plperl and plperlu adopted in release 8.2. In versions 8.0 and up, the use of Perl's POSIX module to undo its locale mangling on Windows has become insecure with these changes, so it is replaced by our own routine, which is also faster. Nice side effects of the changes include that it is now possible to use perl's "strict" pragma in a natural way in plperl, and that perl's $a and $b variables now work as expected in sort routines, and that function compilation is significantly faster. Tim Bunce and Andrew Dunstan, with reviews from Alex Hunsaker and Alexey Klyukin. Security: CVE-2010-1169
2010-05-13 18:39:43 +02:00
HV *stash;
SV *sv;
char *key;
I32 klen;
pgindent run for 9.0, second run
2010-07-06 21:19:02 +02:00
Abandon the use of Perl's Safe.pm to enforce restrictions in plperl, as it is fundamentally insecure. Instead apply an opmask to the whole interpreter that imposes restrictions on unsafe operations. These restrictions are much harder to subvert than is Safe.pm, since there is no container to be broken out of. Backported to release 7.4. In releases 7.4, 8.0 and 8.1 this also includes the necessary backporting of the two interpreters model for plperl and plperlu adopted in release 8.2. In versions 8.0 and up, the use of Perl's POSIX module to undo its locale mangling on Windows has become insecure with these changes, so it is replaced by our own routine, which is also faster. Nice side effects of the changes include that it is now possible to use perl's "strict" pragma in a natural way in plperl, and that perl's $a and $b variables now work as expected in sort routines, and that function compilation is significantly faster. Tim Bunce and Andrew Dunstan, with reviews from Alex Hunsaker and Alexey Klyukin. Security: CVE-2010-1169
2010-05-13 18:39:43 +02:00
/* use original require while we set up */
PL_ppaddr[OP_REQUIRE] = pp_require_orig;
PL_ppaddr[OP_DOFILE] = pp_require_orig;
pgindent run for 9.0, second run
2010-07-06 21:19:02 +02:00
Abandon the use of Perl's Safe.pm to enforce restrictions in plperl, as it is fundamentally insecure. Instead apply an opmask to the whole interpreter that imposes restrictions on unsafe operations. These restrictions are much harder to subvert than is Safe.pm, since there is no container to be broken out of. Backported to release 7.4. In releases 7.4, 8.0 and 8.1 this also includes the necessary backporting of the two interpreters model for plperl and plperlu adopted in release 8.2. In versions 8.0 and up, the use of Perl's POSIX module to undo its locale mangling on Windows has become insecure with these changes, so it is replaced by our own routine, which is also faster. Nice side effects of the changes include that it is now possible to use perl's "strict" pragma in a natural way in plperl, and that perl's $a and $b variables now work as expected in sort routines, and that function compilation is significantly faster. Tim Bunce and Andrew Dunstan, with reviews from Alex Hunsaker and Alexey Klyukin. Security: CVE-2010-1169
2010-05-13 18:39:43 +02:00
eval_pv(PLC_TRUSTED, FALSE);
if (SvTRUE(ERRSV))
ereport(ERROR,
Fix a number of places that produced XX000 errors in the regression tests. It's against project policy to use elog() for user-facing errors, or to omit an errcode() selection for errors that aren't supposed to be "can't happen" cases. Fix all the violations of this policy that result in ERRCODE_INTERNAL_ERROR log entries during the standard regression tests, as errors that can reliably be triggered from SQL surely should be considered user-facing. I also looked through all the files touched by this commit and fixed other nearby problems of the same ilk. I do not claim to have fixed all violations of the policy, just the ones in these files. In a few places I also changed existing ERRCODE choices that didn't seem particularly appropriate; mainly replacing ERRCODE_SYNTAX_ERROR by something more specific. Back-patch to 9.5, but no further; changing ERRCODE assignments in stable branches doesn't seem like a good idea.
2015-08-03 05:49:19 +02:00
(errcode(ERRCODE_EXTERNAL_ROUTINE_EXCEPTION),
errmsg("%s", strip_trailing_ws(sv2cstr(ERRSV))),
Follow up a visit from the style police.
2010-05-17 21:43:04 +02:00
errcontext("while executing PLC_TRUSTED")));
pgindent run for 9.0, second run
2010-07-06 21:19:02 +02:00
Force strings passed to and from plperl to be in UTF8 encoding. String are converted to UTF8 on the way into perl and to the database encoding on the way back. This avoids a number of observed anomalies, and ensures Perl a consistent view of the world. Some minor code cleanups are also accomplished. Alex Hunsaker, reviewed by Andy Colson.
2011-02-06 23:29:26 +01:00
/*
pgindent run on plperl.c
2011-02-17 20:40:13 +01:00
* Force loading of utf8 module now to prevent errors that can arise from
* the regex code later trying to load utf8 modules. See
Force strings passed to and from plperl to be in UTF8 encoding. String are converted to UTF8 on the way into perl and to the database encoding on the way back. This avoids a number of observed anomalies, and ensures Perl a consistent view of the world. Some minor code cleanups are also accomplished. Alex Hunsaker, reviewed by Andy Colson.
2011-02-06 23:29:26 +01:00
* http://rt.perl.org/rt3/Ticket/Display.html?id=47576
*/
eval_pv("my $a=chr(0x100); return $a =~ /\\xa9/i", FALSE);
if (SvTRUE(ERRSV))
ereport(ERROR,
Fix a number of places that produced XX000 errors in the regression tests. It's against project policy to use elog() for user-facing errors, or to omit an errcode() selection for errors that aren't supposed to be "can't happen" cases. Fix all the violations of this policy that result in ERRCODE_INTERNAL_ERROR log entries during the standard regression tests, as errors that can reliably be triggered from SQL surely should be considered user-facing. I also looked through all the files touched by this commit and fixed other nearby problems of the same ilk. I do not claim to have fixed all violations of the policy, just the ones in these files. In a few places I also changed existing ERRCODE choices that didn't seem particularly appropriate; mainly replacing ERRCODE_SYNTAX_ERROR by something more specific. Back-patch to 9.5, but no further; changing ERRCODE assignments in stable branches doesn't seem like a good idea.
2015-08-03 05:49:19 +02:00
(errcode(ERRCODE_EXTERNAL_ROUTINE_EXCEPTION),
errmsg("%s", strip_trailing_ws(sv2cstr(ERRSV))),
Force strings passed to and from plperl to be in UTF8 encoding. String are converted to UTF8 on the way into perl and to the database encoding on the way back. This avoids a number of observed anomalies, and ensures Perl a consistent view of the world. Some minor code cleanups are also accomplished. Alex Hunsaker, reviewed by Andy Colson.
2011-02-06 23:29:26 +01:00
errcontext("while executing utf8fix")));
pgindent run for 9.0, second run
2010-07-06 21:19:02 +02:00
Abandon the use of Perl's Safe.pm to enforce restrictions in plperl, as it is fundamentally insecure. Instead apply an opmask to the whole interpreter that imposes restrictions on unsafe operations. These restrictions are much harder to subvert than is Safe.pm, since there is no container to be broken out of. Backported to release 7.4. In releases 7.4, 8.0 and 8.1 this also includes the necessary backporting of the two interpreters model for plperl and plperlu adopted in release 8.2. In versions 8.0 and up, the use of Perl's POSIX module to undo its locale mangling on Windows has become insecure with these changes, so it is replaced by our own routine, which is also faster. Nice side effects of the changes include that it is now possible to use perl's "strict" pragma in a natural way in plperl, and that perl's $a and $b variables now work as expected in sort routines, and that function compilation is significantly faster. Tim Bunce and Andrew Dunstan, with reviews from Alex Hunsaker and Alexey Klyukin. Security: CVE-2010-1169
2010-05-13 18:39:43 +02:00
/*
* Lock down the interpreter
*/
pgindent run for 9.0, second run
2010-07-06 21:19:02 +02:00
Abandon the use of Perl's Safe.pm to enforce restrictions in plperl, as it is fundamentally insecure. Instead apply an opmask to the whole interpreter that imposes restrictions on unsafe operations. These restrictions are much harder to subvert than is Safe.pm, since there is no container to be broken out of. Backported to release 7.4. In releases 7.4, 8.0 and 8.1 this also includes the necessary backporting of the two interpreters model for plperl and plperlu adopted in release 8.2. In versions 8.0 and up, the use of Perl's POSIX module to undo its locale mangling on Windows has become insecure with these changes, so it is replaced by our own routine, which is also faster. Nice side effects of the changes include that it is now possible to use perl's "strict" pragma in a natural way in plperl, and that perl's $a and $b variables now work as expected in sort routines, and that function compilation is significantly faster. Tim Bunce and Andrew Dunstan, with reviews from Alex Hunsaker and Alexey Klyukin. Security: CVE-2010-1169
2010-05-13 18:39:43 +02:00
/* switch to the safe require/dofile opcode for future code */
PL_ppaddr[OP_REQUIRE] = pp_require_safe;
PL_ppaddr[OP_DOFILE] = pp_require_safe;
pgindent run for 9.0, second run
2010-07-06 21:19:02 +02:00
Abandon the use of Perl's Safe.pm to enforce restrictions in plperl, as it is fundamentally insecure. Instead apply an opmask to the whole interpreter that imposes restrictions on unsafe operations. These restrictions are much harder to subvert than is Safe.pm, since there is no container to be broken out of. Backported to release 7.4. In releases 7.4, 8.0 and 8.1 this also includes the necessary backporting of the two interpreters model for plperl and plperlu adopted in release 8.2. In versions 8.0 and up, the use of Perl's POSIX module to undo its locale mangling on Windows has become insecure with these changes, so it is replaced by our own routine, which is also faster. Nice side effects of the changes include that it is now possible to use perl's "strict" pragma in a natural way in plperl, and that perl's $a and $b variables now work as expected in sort routines, and that function compilation is significantly faster. Tim Bunce and Andrew Dunstan, with reviews from Alex Hunsaker and Alexey Klyukin. Security: CVE-2010-1169
2010-05-13 18:39:43 +02:00
/*
* prevent (any more) unsafe opcodes being compiled PL_op_mask is per
* interpreter, so this only needs to be set once
*/
PL_op_mask = plperl_opmask;
pgindent run for 9.0, second run
2010-07-06 21:19:02 +02:00
Abandon the use of Perl's Safe.pm to enforce restrictions in plperl, as it is fundamentally insecure. Instead apply an opmask to the whole interpreter that imposes restrictions on unsafe operations. These restrictions are much harder to subvert than is Safe.pm, since there is no container to be broken out of. Backported to release 7.4. In releases 7.4, 8.0 and 8.1 this also includes the necessary backporting of the two interpreters model for plperl and plperlu adopted in release 8.2. In versions 8.0 and up, the use of Perl's POSIX module to undo its locale mangling on Windows has become insecure with these changes, so it is replaced by our own routine, which is also faster. Nice side effects of the changes include that it is now possible to use perl's "strict" pragma in a natural way in plperl, and that perl's $a and $b variables now work as expected in sort routines, and that function compilation is significantly faster. Tim Bunce and Andrew Dunstan, with reviews from Alex Hunsaker and Alexey Klyukin. Security: CVE-2010-1169
2010-05-13 18:39:43 +02:00
/* delete the DynaLoader:: namespace so extensions can't be loaded */
stash = gv_stashpv("DynaLoader", GV_ADDWARN);
hv_iterinit(stash);
while ((sv = hv_iternextsv(stash, &key, &klen)))
At 2005-05-21 20:18:50 +0530, ams@oryx.com wrote: > > > The second issue is where plperl returns a large result set. I have attached the following seven patches to address this problem: 1. Trivial. Replaces some errant spaces with tabs. 2. Trivial. Fixes the spelling of Jan's name, and gets rid of many inane, useless, annoying, and often misleading comments. Here's a sample: "plperl_init_all() - Initialize all". (I have tried to add some useful comments here and there, and will continue to do so now and again.) 3. Trivial. Splits up some long lines. 4. Converts SRFs in PL/Perl to use a Tuplestore and SFRM_Materialize to return the result set, based on the PL/PgSQL model. There are two major consequences: result sets will spill to disk when they can no longer fit in work_mem; and "select foo_srf()" no longer works. (I didn't lose sleep over the latter, since that form is not valid in PL/PgSQL, and it's not documented in PL/Perl.) 5. Trivial, but important. Fixes use of "undef" instead of undef. This would cause empty functions to fail in bizarre ways. I suspect that there's still another (old) bug here. I'll investigate further. 6. Moves the majority of (4) out into a new plperl_return_next() function, to make it possible to expose the functionality to Perl; cleans up some of the code besides. 7. Add an spi_return_next function for use in Perl code. If you want to apply the patches and try them out, 8-composite.diff is what you should use. (Note: my patches depend upon Andrew's use-strict and %_SHARED patches being applied.) Here's something to try: create or replace function foo() returns setof record as $$ $i = 0; for ("World", "PostgreSQL", "PL/Perl") { spi_return_next({f1=>++$i, f2=>'Hello', f3=>$_}); } return; $$ language plperl; select * from foo() as (f1 integer, f2 text, f3 text); (Many thanks to Andrews Dunstan and Supernews for their help.) Abhijit Menon-Sen
2005-06-04 22:33:06 +02:00
{
Abandon the use of Perl's Safe.pm to enforce restrictions in plperl, as it is fundamentally insecure. Instead apply an opmask to the whole interpreter that imposes restrictions on unsafe operations. These restrictions are much harder to subvert than is Safe.pm, since there is no container to be broken out of. Backported to release 7.4. In releases 7.4, 8.0 and 8.1 this also includes the necessary backporting of the two interpreters model for plperl and plperlu adopted in release 8.2. In versions 8.0 and up, the use of Perl's POSIX module to undo its locale mangling on Windows has become insecure with these changes, so it is replaced by our own routine, which is also faster. Nice side effects of the changes include that it is now possible to use perl's "strict" pragma in a natural way in plperl, and that perl's $a and $b variables now work as expected in sort routines, and that function compilation is significantly faster. Tim Bunce and Andrew Dunstan, with reviews from Alex Hunsaker and Alexey Klyukin. Security: CVE-2010-1169
2010-05-13 18:39:43 +02:00
if (!isGV_with_GP(sv) || !GvCV(sv))
continue;
SvREFCNT_dec(GvCV(sv)); /* free the CV */
Allow building with perl 5.14. Patch from Alex Hunsaker.
2011-06-05 01:32:10 +02:00
GvCV_set(sv, NULL); /* prevent call via GV */
Abandon the use of Perl's Safe.pm to enforce restrictions in plperl, as it is fundamentally insecure. Instead apply an opmask to the whole interpreter that imposes restrictions on unsafe operations. These restrictions are much harder to subvert than is Safe.pm, since there is no container to be broken out of. Backported to release 7.4. In releases 7.4, 8.0 and 8.1 this also includes the necessary backporting of the two interpreters model for plperl and plperlu adopted in release 8.2. In versions 8.0 and up, the use of Perl's POSIX module to undo its locale mangling on Windows has become insecure with these changes, so it is replaced by our own routine, which is also faster. Nice side effects of the changes include that it is now possible to use perl's "strict" pragma in a natural way in plperl, and that perl's $a and $b variables now work as expected in sort routines, and that function compilation is significantly faster. Tim Bunce and Andrew Dunstan, with reviews from Alex Hunsaker and Alexey Klyukin. Security: CVE-2010-1169
2010-05-13 18:39:43 +02:00
}
hv_clear(stash);
pgindent run for 9.0, second run
2010-07-06 21:19:02 +02:00
Abandon the use of Perl's Safe.pm to enforce restrictions in plperl, as it is fundamentally insecure. Instead apply an opmask to the whole interpreter that imposes restrictions on unsafe operations. These restrictions are much harder to subvert than is Safe.pm, since there is no container to be broken out of. Backported to release 7.4. In releases 7.4, 8.0 and 8.1 this also includes the necessary backporting of the two interpreters model for plperl and plperlu adopted in release 8.2. In versions 8.0 and up, the use of Perl's POSIX module to undo its locale mangling on Windows has become insecure with these changes, so it is replaced by our own routine, which is also faster. Nice side effects of the changes include that it is now possible to use perl's "strict" pragma in a natural way in plperl, and that perl's $a and $b variables now work as expected in sort routines, and that function compilation is significantly faster. Tim Bunce and Andrew Dunstan, with reviews from Alex Hunsaker and Alexey Klyukin. Security: CVE-2010-1169
2010-05-13 18:39:43 +02:00
/* invalidate assorted caches */
++PL_sub_generation;
hv_clear(PL_stashcache);
pgindent run for 9.0, second run
2010-07-06 21:19:02 +02:00
Abandon the use of Perl's Safe.pm to enforce restrictions in plperl, as it is fundamentally insecure. Instead apply an opmask to the whole interpreter that imposes restrictions on unsafe operations. These restrictions are much harder to subvert than is Safe.pm, since there is no container to be broken out of. Backported to release 7.4. In releases 7.4, 8.0 and 8.1 this also includes the necessary backporting of the two interpreters model for plperl and plperlu adopted in release 8.2. In versions 8.0 and up, the use of Perl's POSIX module to undo its locale mangling on Windows has become insecure with these changes, so it is replaced by our own routine, which is also faster. Nice side effects of the changes include that it is now possible to use perl's "strict" pragma in a natural way in plperl, and that perl's $a and $b variables now work as expected in sort routines, and that function compilation is significantly faster. Tim Bunce and Andrew Dunstan, with reviews from Alex Hunsaker and Alexey Klyukin. Security: CVE-2010-1169
2010-05-13 18:39:43 +02:00
/*
* Execute plperl.on_plperl_init in the locked-down interpreter
*/
if (plperl_on_plperl_init && *plperl_on_plperl_init)
{
eval_pv(plperl_on_plperl_init, FALSE);
Fix a number of places that produced XX000 errors in the regression tests. It's against project policy to use elog() for user-facing errors, or to omit an errcode() selection for errors that aren't supposed to be "can't happen" cases. Fix all the violations of this policy that result in ERRCODE_INTERNAL_ERROR log entries during the standard regression tests, as errors that can reliably be triggered from SQL surely should be considered user-facing. I also looked through all the files touched by this commit and fixed other nearby problems of the same ilk. I do not claim to have fixed all violations of the policy, just the ones in these files. In a few places I also changed existing ERRCODE choices that didn't seem particularly appropriate; mainly replacing ERRCODE_SYNTAX_ERROR by something more specific. Back-patch to 9.5, but no further; changing ERRCODE assignments in stable branches doesn't seem like a good idea.
2015-08-03 05:49:19 +02:00
/* XXX need to find a way to determine a better errcode here */
Various small improvements and cleanups for PL/Perl. - Allow (ineffective) use of 'require' in plperl If the required module is not already loaded then it dies. So "use strict;" now works in plperl. - Pre-load the feature module if perl >= 5.10. So "use feature :5.10;" now works in plperl. - Stored procedure subs are now given names. The names are not visible in ordinary use, but they make tools like Devel::NYTProf and Devel::Cover much more useful. - Simplified and generalized the subroutine creation code. Now one code path for generating sub source code, not four. Can generate multiple 'use' statements with specific imports (which handles plperl.use_strict currently and can easily be extended to handle a plperl.use_feature=':5.12' in future). - Disallows use of Safe version 2.20 which is broken for PL/Perl. http://rt.perl.org/rt3/Ticket/Display.html?id=72068 - Assorted minor optimizations by pre-growing data structures. Patch from Tim Bunce, reviewed by Alex Hunsaker.
2010-01-27 00:11:56 +01:00
if (SvTRUE(ERRSV))
ereport(ERROR,
Fix a number of places that produced XX000 errors in the regression tests. It's against project policy to use elog() for user-facing errors, or to omit an errcode() selection for errors that aren't supposed to be "can't happen" cases. Fix all the violations of this policy that result in ERRCODE_INTERNAL_ERROR log entries during the standard regression tests, as errors that can reliably be triggered from SQL surely should be considered user-facing. I also looked through all the files touched by this commit and fixed other nearby problems of the same ilk. I do not claim to have fixed all violations of the policy, just the ones in these files. In a few places I also changed existing ERRCODE choices that didn't seem particularly appropriate; mainly replacing ERRCODE_SYNTAX_ERROR by something more specific. Back-patch to 9.5, but no further; changing ERRCODE assignments in stable branches doesn't seem like a good idea.
2015-08-03 05:49:19 +02:00
(errcode(ERRCODE_EXTERNAL_ROUTINE_EXCEPTION),
errmsg("%s", strip_trailing_ws(sv2cstr(ERRSV))),
Follow up a visit from the style police.
2010-05-17 21:43:04 +02:00
errcontext("while executing plperl.on_plperl_init")));
Add plperl.on_plperl_init and plperl.on_plperlu_init settings for language-specific startup. Rename recently added plperl.on_perl_init to plperl.on_init. Also, code cleanup for utf8 hack. Patch from Tim Bunce, reviewed by Alex Hunsaker.
2010-02-12 20:35:25 +01:00
}
}
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
/*
* Initialize the current Perl interpreter as an untrusted interp
*/
Add plperl.on_plperl_init and plperl.on_plperlu_init settings for language-specific startup. Rename recently added plperl.on_perl_init to plperl.on_init. Also, code cleanup for utf8 hack. Patch from Tim Bunce, reviewed by Alex Hunsaker.
2010-02-12 20:35:25 +01:00
static void
plperl_untrusted_init(void)
{
PL/Perl portability fix: avoid including XSUB.h in plperl.c. In Perl builds that define PERL_IMPLICIT_SYS, XSUB.h defines macros that replace a whole lot of basic libc functions with Perl functions. We can't tolerate that in plperl.c; it breaks at least PG_TRY and probably other stuff. The core idea of this patch is to include XSUB.h only in the .xs files where it's really needed, and to move any code broken by PERL_IMPLICIT_SYS out of the .xs files and into plperl.c. The reason this hasn't been a problem before is that our build techniques did not result in PERL_IMPLICIT_SYS appearing as a #define in PL/Perl, even on some platforms where Perl thinks it is defined. That's about to change in order to fix a nasty portability issue, so we need this work to make the code safe for that. Rather unaccountably, the Perl people chose XSUB.h as the place to provide the versions of the aTHX/aTHX_ macros that are needed by code that's not explicitly aware of the MULTIPLICITY API conventions. Hence, just removing XSUB.h from plperl.c fails miserably. But we can work around that by defining PERL_NO_GET_CONTEXT (which would make the relevant stanza of XSUB.h a no-op anyway). As explained in perlguts.pod, that means we need to add a "dTHX" macro call in every C function that calls a Perl API function. In most of them we just add this at the top; but since the macro fetches the current Perl interpreter pointer, more care is needed in functions that switch the active interpreter. Lack of the macro is easily recognized since it results in bleats about "my_perl" not being defined. (A nice side benefit of this is that it significantly reduces the number of fetches of the current interpreter pointer. On my machine, plperl.so gets more than 10% smaller, and there's probably some performance win too. We could reduce the number of fetches still more by decorating the code with pTHX_/aTHX_ macros to pass the interpreter pointer around, as explained by perlguts.pod; but that's a task for another day.) Formatting note: pgindent seems happy to treat "dTHX;" as a declaration so long as it's the first thing after the left brace, as we'd already observed with respect to the similar macro "dSP;". If you try to put it later in a set of declarations, pgindent puts ugly extra space around it. Having removed XSUB.h from plperl.c, we need only move the support functions for spi_return_next and util_elog (both of which use PG_TRY) out of the .xs files and into plperl.c. This seems sufficient to avoid the known problems caused by PERL_IMPLICIT_SYS, although we could move more code if additional issues emerge. This will need to be back-patched, but first let's see what the buildfarm makes of it. Patch by me, with some help from Ashutosh Sharma Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
2017-07-28 18:25:43 +02:00
dTHX;
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
/*
* Nothing to do except execute plperl.on_plperlu_init
*/
Add plperl.on_plperl_init and plperl.on_plperlu_init settings for language-specific startup. Rename recently added plperl.on_perl_init to plperl.on_init. Also, code cleanup for utf8 hack. Patch from Tim Bunce, reviewed by Alex Hunsaker.
2010-02-12 20:35:25 +01:00
if (plperl_on_plperlu_init && *plperl_on_plperlu_init)
{
eval_pv(plperl_on_plperlu_init, FALSE);
if (SvTRUE(ERRSV))
ereport(ERROR,
Fix a number of places that produced XX000 errors in the regression tests. It's against project policy to use elog() for user-facing errors, or to omit an errcode() selection for errors that aren't supposed to be "can't happen" cases. Fix all the violations of this policy that result in ERRCODE_INTERNAL_ERROR log entries during the standard regression tests, as errors that can reliably be triggered from SQL surely should be considered user-facing. I also looked through all the files touched by this commit and fixed other nearby problems of the same ilk. I do not claim to have fixed all violations of the policy, just the ones in these files. In a few places I also changed existing ERRCODE choices that didn't seem particularly appropriate; mainly replacing ERRCODE_SYNTAX_ERROR by something more specific. Back-patch to 9.5, but no further; changing ERRCODE assignments in stable branches doesn't seem like a good idea.
2015-08-03 05:49:19 +02:00
(errcode(ERRCODE_EXTERNAL_ROUTINE_EXCEPTION),
errmsg("%s", strip_trailing_ws(sv2cstr(ERRSV))),
Message style tuning
2010-03-17 22:31:17 +01:00
errcontext("while executing plperl.on_plperlu_init")));
At 2005-05-21 20:18:50 +0530, ams@oryx.com wrote: > > > The second issue is where plperl returns a large result set. I have attached the following seven patches to address this problem: 1. Trivial. Replaces some errant spaces with tabs. 2. Trivial. Fixes the spelling of Jan's name, and gets rid of many inane, useless, annoying, and often misleading comments. Here's a sample: "plperl_init_all() - Initialize all". (I have tried to add some useful comments here and there, and will continue to do so now and again.) 3. Trivial. Splits up some long lines. 4. Converts SRFs in PL/Perl to use a Tuplestore and SFRM_Materialize to return the result set, based on the PL/PgSQL model. There are two major consequences: result sets will spill to disk when they can no longer fit in work_mem; and "select foo_srf()" no longer works. (I didn't lose sleep over the latter, since that form is not valid in PL/PgSQL, and it's not documented in PL/Perl.) 5. Trivial, but important. Fixes use of "undef" instead of undef. This would cause empty functions to fail in bizarre ways. I suspect that there's still another (old) bug here. I'll investigate further. 6. Moves the majority of (4) out into a new plperl_return_next() function, to make it possible to expose the functionality to Perl; cleans up some of the code besides. 7. Add an spi_return_next function for use in Perl code. If you want to apply the patches and try them out, 8-composite.diff is what you should use. (Note: my patches depend upon Andrew's use-strict and %_SHARED patches being applied.) Here's something to try: create or replace function foo() returns setof record as $$ $i = 0; for ("World", "PostgreSQL", "PL/Perl") { spi_return_next({f1=>++$i, f2=>'Hello', f3=>$_}); } return; $$ language plperl; select * from foo() as (f1 integer, f2 text, f3 text); (Many thanks to Andrews Dunstan and Supernews for their help.) Abhijit Menon-Sen
2005-06-04 22:33:06 +02:00
}
The attached patch, which incorporates the previous one sent and currently unapplied regarding spi_internal.c, makes some additional fixes relating to return types, and also contains the fix for preventing the use of insecure versions of Safe.pm. There is one remaing return case that does not appear to work, namely return of a composite directly in a select, i.e. if foo returns some composite type, 'select * from foo()' works but 'select foo()' doesn't. We will either fix that or document it as a limitation. The function plperl_func_handler is a mess - I will try to get it cleaned up (and split up) in a subsequent patch, time permitting. Also, reiterating previous advice - this changes slightly the API for spi_exec_query - the returned object has either 2 or 3 members: 'status' (string) and 'proceesed' (int,- number of rows) and, if rows are returned, 'rows' (array of tuple hashes). Andrew Dunstan
2004-07-12 16:31:04 +02:00
}
Add plperl.on_plperl_init and plperl.on_plperlu_init settings for language-specific startup. Rename recently added plperl.on_perl_init to plperl.on_init. Also, code cleanup for utf8 hack. Patch from Tim Bunce, reviewed by Alex Hunsaker.
2010-02-12 20:35:25 +01:00
Fix plperl's elog() function to convert elog(ERROR) into Perl croak(), rather than longjmp'ing clear out of Perl and thereby leaving Perl in a broken state. Also some minor prettification of error messages. Still need to do something with spi_exec_query() error handling.
2004-11-20 20:07:40 +01:00
/*
* Perl likes to put a newline after its error messages; clean up such
*/
static char *
strip_trailing_ws(const char *msg)
{
char *res = pstrdup(msg);
int len = strlen(res);
while (len > 0 && isspace((unsigned char) res[len - 1]))
res[--len] = '\0';
return res;
}
At 2005-05-21 20:18:50 +0530, ams@oryx.com wrote: > > > The second issue is where plperl returns a large result set. I have attached the following seven patches to address this problem: 1. Trivial. Replaces some errant spaces with tabs. 2. Trivial. Fixes the spelling of Jan's name, and gets rid of many inane, useless, annoying, and often misleading comments. Here's a sample: "plperl_init_all() - Initialize all". (I have tried to add some useful comments here and there, and will continue to do so now and again.) 3. Trivial. Splits up some long lines. 4. Converts SRFs in PL/Perl to use a Tuplestore and SFRM_Materialize to return the result set, based on the PL/PgSQL model. There are two major consequences: result sets will spill to disk when they can no longer fit in work_mem; and "select foo_srf()" no longer works. (I didn't lose sleep over the latter, since that form is not valid in PL/PgSQL, and it's not documented in PL/Perl.) 5. Trivial, but important. Fixes use of "undef" instead of undef. This would cause empty functions to fail in bizarre ways. I suspect that there's still another (old) bug here. I'll investigate further. 6. Moves the majority of (4) out into a new plperl_return_next() function, to make it possible to expose the functionality to Perl; cleans up some of the code besides. 7. Add an spi_return_next function for use in Perl code. If you want to apply the patches and try them out, 8-composite.diff is what you should use. (Note: my patches depend upon Andrew's use-strict and %_SHARED patches being applied.) Here's something to try: create or replace function foo() returns setof record as $$ $i = 0; for ("World", "PostgreSQL", "PL/Perl") { spi_return_next({f1=>++$i, f2=>'Hello', f3=>$_}); } return; $$ language plperl; select * from foo() as (f1 integer, f2 text, f3 text); (Many thanks to Andrews Dunstan and Supernews for their help.) Abhijit Menon-Sen
2005-06-04 22:33:06 +02:00
/* Build a tuple from a hash. */
Further plperl cleanup: be more paranoid about checking the type of data returned from Perl. Consolidate multiple bits of code to convert a Perl hash to a tuple, and drive the conversion off the keys present in the hash rather than the tuple column names, so we detect error if the hash contains keys it shouldn't. (This means keys not in the hash will silently default to NULL, which seems ok to me.) Fix a bunch of reference-count leaks too.
2004-11-23 01:21:24 +01:00
static HeapTuple
Fix up Perl-to-Postgres datatype conversions in pl/perl. This patch restores the pre-9.1 behavior that pl/perl functions returning VOID ignore the result value of their last Perl statement. 9.1.0 unintentionally threw an error if the last statement returned a reference, as reported by Amit Khandekar. Also, make sure it works to return a string value for a composite type, so long as the string meets the type's input format. We already allowed the equivalent behavior for arrays, so it seems inconsistent to not allow it for composites. In addition, ensure we throw errors for attempts to return arrays or hashes when the function's declared result type is not an array or composite type, respectively. Pre-9.1 versions rather uselessly returned strings like ARRAY(0x221a9a0) or HASH(0x221aa90), while 9.1.0 threw an error for the hash case and returned a garbage value for the array case. Also, clean up assorted grotty coding in Perl array conversion, including use of a session-lifespan memory context to accumulate the array value (resulting in session-lifespan memory leak on error), failure to apply the declared typmod if any, and failure to detect some cases of non-rectangular multi-dimensional arrays. Alex Hunsaker and Tom Lane
2011-10-14 00:02:43 +02:00
plperl_build_tuple_result(HV *perlhash, TupleDesc td)
I have attached 5 patches (split up for ease of review) to plperl.c. 1. Two minor cleanups: - We don't need to call hv_exists+hv_fetch; we should just check the return value of hv_fetch. - newSVpv("undef",0) is the string "undef", not a real undef. 2. This should fix the bug Andrew Dunstan described in a recent -hackers post. It replaces three bogus "eval_pv(key, 0)" calls with newSVpv, and eliminates another redundant hv_exists+hv_fetch pair. 3. plperl_build_tuple_argument builds up a string of Perl code to create a hash representing the tuple. This patch creates the hash directly. 4. Another minor cleanup: replace a couple of av_store()s with av_push. 5. Analogous to #3 for plperl_trigger_build_args. This patch removes the static sv_add_tuple_value function, which does much the same as two other utility functions defined later, and merges the functionality into plperl_hash_from_tuple. I have tested the patches to the best of my limited ability, but I would appreciate it very much if someone else could review and test them too. (Thanks to Andrew and David Fetter for their help with some testing.) Abhijit Menon-Sen
2004-10-15 19:08:26 +02:00
{
PL/Perl portability fix: avoid including XSUB.h in plperl.c. In Perl builds that define PERL_IMPLICIT_SYS, XSUB.h defines macros that replace a whole lot of basic libc functions with Perl functions. We can't tolerate that in plperl.c; it breaks at least PG_TRY and probably other stuff. The core idea of this patch is to include XSUB.h only in the .xs files where it's really needed, and to move any code broken by PERL_IMPLICIT_SYS out of the .xs files and into plperl.c. The reason this hasn't been a problem before is that our build techniques did not result in PERL_IMPLICIT_SYS appearing as a #define in PL/Perl, even on some platforms where Perl thinks it is defined. That's about to change in order to fix a nasty portability issue, so we need this work to make the code safe for that. Rather unaccountably, the Perl people chose XSUB.h as the place to provide the versions of the aTHX/aTHX_ macros that are needed by code that's not explicitly aware of the MULTIPLICITY API conventions. Hence, just removing XSUB.h from plperl.c fails miserably. But we can work around that by defining PERL_NO_GET_CONTEXT (which would make the relevant stanza of XSUB.h a no-op anyway). As explained in perlguts.pod, that means we need to add a "dTHX" macro call in every C function that calls a Perl API function. In most of them we just add this at the top; but since the macro fetches the current Perl interpreter pointer, more care is needed in functions that switch the active interpreter. Lack of the macro is easily recognized since it results in bleats about "my_perl" not being defined. (A nice side benefit of this is that it significantly reduces the number of fetches of the current interpreter pointer. On my machine, plperl.so gets more than 10% smaller, and there's probably some performance win too. We could reduce the number of fetches still more by decorating the code with pTHX_/aTHX_ macros to pass the interpreter pointer around, as explained by perlguts.pod; but that's a task for another day.) Formatting note: pgindent seems happy to treat "dTHX;" as a declaration so long as it's the first thing after the left brace, as we'd already observed with respect to the similar macro "dSP;". If you try to put it later in a set of declarations, pgindent puts ugly extra space around it. Having removed XSUB.h from plperl.c, we need only move the support functions for spi_return_next and util_elog (both of which use PG_TRY) out of the .xs files and into plperl.c. This seems sufficient to avoid the known problems caused by PERL_IMPLICIT_SYS, although we could move more code if additional issues emerge. This will need to be back-patched, but first let's see what the buildfarm makes of it. Patch by me, with some help from Ashutosh Sharma Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
2017-07-28 18:25:43 +02:00
dTHX;
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
Datum *values;
bool *nulls;
pgindent run on plperl.c
2011-02-17 20:40:13 +01:00
HE *he;
Further plperl cleanup: be more paranoid about checking the type of data returned from Perl. Consolidate multiple bits of code to convert a Perl hash to a tuple, and drive the conversion off the keys present in the hash rather than the tuple column names, so we detect error if the hash contains keys it shouldn't. (This means keys not in the hash will silently default to NULL, which seems ok to me.) Fix a bunch of reference-count leaks too.
2004-11-23 01:21:24 +01:00
HeapTuple tup;
I have attached 5 patches (split up for ease of review) to plperl.c. 1. Two minor cleanups: - We don't need to call hv_exists+hv_fetch; we should just check the return value of hv_fetch. - newSVpv("undef",0) is the string "undef", not a real undef. 2. This should fix the bug Andrew Dunstan described in a recent -hackers post. It replaces three bogus "eval_pv(key, 0)" calls with newSVpv, and eliminates another redundant hv_exists+hv_fetch pair. 3. plperl_build_tuple_argument builds up a string of Perl code to create a hash representing the tuple. This patch creates the hash directly. 4. Another minor cleanup: replace a couple of av_store()s with av_push. 5. Analogous to #3 for plperl_trigger_build_args. This patch removes the static sv_add_tuple_value function, which does much the same as two other utility functions defined later, and merges the functionality into plperl_hash_from_tuple. I have tested the patches to the best of my limited ability, but I would appreciate it very much if someone else could review and test them too. (Thanks to Andrew and David Fetter for their help with some testing.) Abhijit Menon-Sen
2004-10-15 19:08:26 +02:00
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
values = palloc0(sizeof(Datum) * td->natts);
nulls = palloc(sizeof(bool) * td->natts);
memset(nulls, true, sizeof(bool) * td->natts);
I have attached 5 patches (split up for ease of review) to plperl.c. 1. Two minor cleanups: - We don't need to call hv_exists+hv_fetch; we should just check the return value of hv_fetch. - newSVpv("undef",0) is the string "undef", not a real undef. 2. This should fix the bug Andrew Dunstan described in a recent -hackers post. It replaces three bogus "eval_pv(key, 0)" calls with newSVpv, and eliminates another redundant hv_exists+hv_fetch pair. 3. plperl_build_tuple_argument builds up a string of Perl code to create a hash representing the tuple. This patch creates the hash directly. 4. Another minor cleanup: replace a couple of av_store()s with av_push. 5. Analogous to #3 for plperl_trigger_build_args. This patch removes the static sv_add_tuple_value function, which does much the same as two other utility functions defined later, and merges the functionality into plperl_hash_from_tuple. I have tested the patches to the best of my limited ability, but I would appreciate it very much if someone else could review and test them too. (Thanks to Andrew and David Fetter for their help with some testing.) Abhijit Menon-Sen
2004-10-15 19:08:26 +02:00
Further plperl cleanup: be more paranoid about checking the type of data returned from Perl. Consolidate multiple bits of code to convert a Perl hash to a tuple, and drive the conversion off the keys present in the hash rather than the tuple column names, so we detect error if the hash contains keys it shouldn't. (This means keys not in the hash will silently default to NULL, which seems ok to me.) Fix a bunch of reference-count leaks too.
2004-11-23 01:21:24 +01:00
hv_iterinit(perlhash);
Force strings passed to and from plperl to be in UTF8 encoding. String are converted to UTF8 on the way into perl and to the database encoding on the way back. This avoids a number of observed anomalies, and ensures Perl a consistent view of the world. Some minor code cleanups are also accomplished. Alex Hunsaker, reviewed by Andy Colson.
2011-02-06 23:29:26 +01:00
while ((he = hv_iternext(perlhash)))
Further plperl cleanup: be more paranoid about checking the type of data returned from Perl. Consolidate multiple bits of code to convert a Perl hash to a tuple, and drive the conversion off the keys present in the hash rather than the tuple column names, so we detect error if the hash contains keys it shouldn't. (This means keys not in the hash will silently default to NULL, which seems ok to me.) Fix a bunch of reference-count leaks too.
2004-11-23 01:21:24 +01:00
{
pgindent run on plperl.c
2011-02-17 20:40:13 +01:00
SV *val = HeVAL(he);
char *key = hek2cstr(he);
int attn = SPI_fnumber(td, key);
Change tupledesc->attrs[n] to TupleDescAttr(tupledesc, n). This is a mechanical change in preparation for a later commit that will change the layout of TupleDesc. Introducing a macro to abstract the details of where attributes are stored will allow us to change that in separate step and revise it in future. Author: Thomas Munro, editorialized by Andres Freund Reviewed-By: Andres Freund Discussion: https://postgr.es/m/CAEepm=0ZtQ-SpsgCyzzYpsXS6e=kZWqk3g5Ygn3MDV7A8dabUA@mail.gmail.com
2017-08-20 20:19:07 +02:00
Form_pg_attribute attr = TupleDescAttr(td, attn - 1);
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
Make SPI_fnumber() reject dropped columns. There's basically no scenario where it's sensible for this to match dropped columns, so put a test for dropped-ness into SPI_fnumber() itself, and excise the test from the small number of callers that were paying attention to the case. (Most weren't :-(.) In passing, normalize tests at call sites: always reject attnum <= 0 if we're disallowing system columns. Previously there was a mixture of "< 0" and "<= 0" tests. This makes no practical difference since SPI_fnumber() never returns 0, but I'm feeling pedantic today. Also, in the places that are actually live user-facing code and not legacy cruft, distinguish "column not found" from "can't handle system column". Per discussion with Jim Nasby; thi supersedes his original patch that just changed the behavior at one call site. Discussion: <b2de8258-c4c0-1cb8-7b97-e8538e5c975c@BlueTreble.com>
2016-11-08 19:11:15 +01:00
if (attn == SPI_ERROR_NOATTRIBUTE)
Update plperl to use ereport() not elog() for user-facing messages, so that they will be translatable. Give messages some semblance of conformance to the style guide.
2004-11-29 21:11:06 +01:00
ereport(ERROR,
(errcode(ERRCODE_UNDEFINED_COLUMN),
errmsg("Perl hash contains nonexistent column \"%s\"",
key)));
Make SPI_fnumber() reject dropped columns. There's basically no scenario where it's sensible for this to match dropped columns, so put a test for dropped-ness into SPI_fnumber() itself, and excise the test from the small number of callers that were paying attention to the case. (Most weren't :-(.) In passing, normalize tests at call sites: always reject attnum <= 0 if we're disallowing system columns. Previously there was a mixture of "< 0" and "<= 0" tests. This makes no practical difference since SPI_fnumber() never returns 0, but I'm feeling pedantic today. Also, in the places that are actually live user-facing code and not legacy cruft, distinguish "column not found" from "can't handle system column". Per discussion with Jim Nasby; thi supersedes his original patch that just changed the behavior at one call site. Discussion: <b2de8258-c4c0-1cb8-7b97-e8538e5c975c@BlueTreble.com>
2016-11-08 19:11:15 +01:00
if (attn <= 0)
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("cannot set system attribute \"%s\"",
key)));
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
values[attn - 1] = plperl_sv_to_datum(val,
Change tupledesc->attrs[n] to TupleDescAttr(tupledesc, n). This is a mechanical change in preparation for a later commit that will change the layout of TupleDesc. Introducing a macro to abstract the details of where attributes are stored will allow us to change that in separate step and revise it in future. Author: Thomas Munro, editorialized by Andres Freund Reviewed-By: Andres Freund Discussion: https://postgr.es/m/CAEepm=0ZtQ-SpsgCyzzYpsXS6e=kZWqk3g5Ygn3MDV7A8dabUA@mail.gmail.com
2017-08-20 20:19:07 +02:00
attr->atttypid,
attr->atttypmod,
Fix up Perl-to-Postgres datatype conversions in pl/perl. This patch restores the pre-9.1 behavior that pl/perl functions returning VOID ignore the result value of their last Perl statement. 9.1.0 unintentionally threw an error if the last statement returned a reference, as reported by Amit Khandekar. Also, make sure it works to return a string value for a composite type, so long as the string meets the type's input format. We already allowed the equivalent behavior for arrays, so it seems inconsistent to not allow it for composites. In addition, ensure we throw errors for attempts to return arrays or hashes when the function's declared result type is not an array or composite type, respectively. Pre-9.1 versions rather uselessly returned strings like ARRAY(0x221a9a0) or HASH(0x221aa90), while 9.1.0 threw an error for the hash case and returned a garbage value for the array case. Also, clean up assorted grotty coding in Perl array conversion, including use of a session-lifespan memory context to accumulate the array value (resulting in session-lifespan memory leak on error), failure to apply the declared typmod if any, and failure to detect some cases of non-rectangular multi-dimensional arrays. Alex Hunsaker and Tom Lane
2011-10-14 00:02:43 +02:00
NULL,
NULL,
InvalidOid,
&nulls[attn - 1]);
Force strings passed to and from plperl to be in UTF8 encoding. String are converted to UTF8 on the way into perl and to the database encoding on the way back. This avoids a number of observed anomalies, and ensures Perl a consistent view of the world. Some minor code cleanups are also accomplished. Alex Hunsaker, reviewed by Andy Colson.
2011-02-06 23:29:26 +01:00
pfree(key);
I have attached 5 patches (split up for ease of review) to plperl.c. 1. Two minor cleanups: - We don't need to call hv_exists+hv_fetch; we should just check the return value of hv_fetch. - newSVpv("undef",0) is the string "undef", not a real undef. 2. This should fix the bug Andrew Dunstan described in a recent -hackers post. It replaces three bogus "eval_pv(key, 0)" calls with newSVpv, and eliminates another redundant hv_exists+hv_fetch pair. 3. plperl_build_tuple_argument builds up a string of Perl code to create a hash representing the tuple. This patch creates the hash directly. 4. Another minor cleanup: replace a couple of av_store()s with av_push. 5. Analogous to #3 for plperl_trigger_build_args. This patch removes the static sv_add_tuple_value function, which does much the same as two other utility functions defined later, and merges the functionality into plperl_hash_from_tuple. I have tested the patches to the best of my limited ability, but I would appreciate it very much if someone else could review and test them too. (Thanks to Andrew and David Fetter for their help with some testing.) Abhijit Menon-Sen
2004-10-15 19:08:26 +02:00
}
Further plperl cleanup: be more paranoid about checking the type of data returned from Perl. Consolidate multiple bits of code to convert a Perl hash to a tuple, and drive the conversion off the keys present in the hash rather than the tuple column names, so we detect error if the hash contains keys it shouldn't. (This means keys not in the hash will silently default to NULL, which seems ok to me.) Fix a bunch of reference-count leaks too.
2004-11-23 01:21:24 +01:00
hv_iterinit(perlhash);
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
tup = heap_form_tuple(td, values, nulls);
pfree(values);
pfree(nulls);
return tup;
}
Force strings passed to and from plperl to be in UTF8 encoding. String are converted to UTF8 on the way into perl and to the database encoding on the way back. This avoids a number of observed anomalies, and ensures Perl a consistent view of the world. Some minor code cleanups are also accomplished. Alex Hunsaker, reviewed by Andy Colson.
2011-02-06 23:29:26 +01:00
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
/* convert a hash reference to a datum */
static Datum
plperl_hash_to_datum(SV *src, TupleDesc td)
{
Fix up Perl-to-Postgres datatype conversions in pl/perl. This patch restores the pre-9.1 behavior that pl/perl functions returning VOID ignore the result value of their last Perl statement. 9.1.0 unintentionally threw an error if the last statement returned a reference, as reported by Amit Khandekar. Also, make sure it works to return a string value for a composite type, so long as the string meets the type's input format. We already allowed the equivalent behavior for arrays, so it seems inconsistent to not allow it for composites. In addition, ensure we throw errors for attempts to return arrays or hashes when the function's declared result type is not an array or composite type, respectively. Pre-9.1 versions rather uselessly returned strings like ARRAY(0x221a9a0) or HASH(0x221aa90), while 9.1.0 threw an error for the hash case and returned a garbage value for the array case. Also, clean up assorted grotty coding in Perl array conversion, including use of a session-lifespan memory context to accumulate the array value (resulting in session-lifespan memory leak on error), failure to apply the declared typmod if any, and failure to detect some cases of non-rectangular multi-dimensional arrays. Alex Hunsaker and Tom Lane
2011-10-14 00:02:43 +02:00
HeapTuple tup = plperl_build_tuple_result((HV *) SvRV(src), td);
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
return HeapTupleGetDatum(tup);
}
/*
* if we are an array ref return the reference. this is special in that if we
* are a PostgreSQL::InServer::ARRAY object we will return the 'magic' array.
*/
static SV *
get_perl_array_ref(SV *sv)
{
PL/Perl portability fix: avoid including XSUB.h in plperl.c. In Perl builds that define PERL_IMPLICIT_SYS, XSUB.h defines macros that replace a whole lot of basic libc functions with Perl functions. We can't tolerate that in plperl.c; it breaks at least PG_TRY and probably other stuff. The core idea of this patch is to include XSUB.h only in the .xs files where it's really needed, and to move any code broken by PERL_IMPLICIT_SYS out of the .xs files and into plperl.c. The reason this hasn't been a problem before is that our build techniques did not result in PERL_IMPLICIT_SYS appearing as a #define in PL/Perl, even on some platforms where Perl thinks it is defined. That's about to change in order to fix a nasty portability issue, so we need this work to make the code safe for that. Rather unaccountably, the Perl people chose XSUB.h as the place to provide the versions of the aTHX/aTHX_ macros that are needed by code that's not explicitly aware of the MULTIPLICITY API conventions. Hence, just removing XSUB.h from plperl.c fails miserably. But we can work around that by defining PERL_NO_GET_CONTEXT (which would make the relevant stanza of XSUB.h a no-op anyway). As explained in perlguts.pod, that means we need to add a "dTHX" macro call in every C function that calls a Perl API function. In most of them we just add this at the top; but since the macro fetches the current Perl interpreter pointer, more care is needed in functions that switch the active interpreter. Lack of the macro is easily recognized since it results in bleats about "my_perl" not being defined. (A nice side benefit of this is that it significantly reduces the number of fetches of the current interpreter pointer. On my machine, plperl.so gets more than 10% smaller, and there's probably some performance win too. We could reduce the number of fetches still more by decorating the code with pTHX_/aTHX_ macros to pass the interpreter pointer around, as explained by perlguts.pod; but that's a task for another day.) Formatting note: pgindent seems happy to treat "dTHX;" as a declaration so long as it's the first thing after the left brace, as we'd already observed with respect to the similar macro "dSP;". If you try to put it later in a set of declarations, pgindent puts ugly extra space around it. Having removed XSUB.h from plperl.c, we need only move the support functions for spi_return_next and util_elog (both of which use PG_TRY) out of the .xs files and into plperl.c. This seems sufficient to avoid the known problems caused by PERL_IMPLICIT_SYS, although we could move more code if additional issues emerge. This will need to be back-patched, but first let's see what the buildfarm makes of it. Patch by me, with some help from Ashutosh Sharma Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
2017-07-28 18:25:43 +02:00
dTHX;
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
if (SvOK(sv) && SvROK(sv))
Force strings passed to and from plperl to be in UTF8 encoding. String are converted to UTF8 on the way into perl and to the database encoding on the way back. This avoids a number of observed anomalies, and ensures Perl a consistent view of the world. Some minor code cleanups are also accomplished. Alex Hunsaker, reviewed by Andy Colson.
2011-02-06 23:29:26 +01:00
{
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
if (SvTYPE(SvRV(sv)) == SVt_PVAV)
return sv;
else if (sv_isa(sv, "PostgreSQL::InServer::ARRAY"))
{
HV *hv = (HV *) SvRV(sv);
SV **sav = hv_fetch_string(hv, "array");
if (*sav && SvOK(*sav) && SvROK(*sav) &&
SvTYPE(SvRV(*sav)) == SVt_PVAV)
return *sav;
elog(ERROR, "could not get array reference from PostgreSQL::InServer::ARRAY object");
}
Force strings passed to and from plperl to be in UTF8 encoding. String are converted to UTF8 on the way into perl and to the database encoding on the way back. This avoids a number of observed anomalies, and ensures Perl a consistent view of the world. Some minor code cleanups are also accomplished. Alex Hunsaker, reviewed by Andy Colson.
2011-02-06 23:29:26 +01:00
}
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
return NULL;
}
Force strings passed to and from plperl to be in UTF8 encoding. String are converted to UTF8 on the way into perl and to the database encoding on the way back. This avoids a number of observed anomalies, and ensures Perl a consistent view of the world. Some minor code cleanups are also accomplished. Alex Hunsaker, reviewed by Andy Colson.
2011-02-06 23:29:26 +01:00
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
/*
Fix up Perl-to-Postgres datatype conversions in pl/perl. This patch restores the pre-9.1 behavior that pl/perl functions returning VOID ignore the result value of their last Perl statement. 9.1.0 unintentionally threw an error if the last statement returned a reference, as reported by Amit Khandekar. Also, make sure it works to return a string value for a composite type, so long as the string meets the type's input format. We already allowed the equivalent behavior for arrays, so it seems inconsistent to not allow it for composites. In addition, ensure we throw errors for attempts to return arrays or hashes when the function's declared result type is not an array or composite type, respectively. Pre-9.1 versions rather uselessly returned strings like ARRAY(0x221a9a0) or HASH(0x221aa90), while 9.1.0 threw an error for the hash case and returned a garbage value for the array case. Also, clean up assorted grotty coding in Perl array conversion, including use of a session-lifespan memory context to accumulate the array value (resulting in session-lifespan memory leak on error), failure to apply the declared typmod if any, and failure to detect some cases of non-rectangular multi-dimensional arrays. Alex Hunsaker and Tom Lane
2011-10-14 00:02:43 +02:00
* helper function for plperl_array_to_datum, recurses for multi-D arrays
Tighten array dimensionality checks in Perl -> SQL array conversion. plperl_array_to_datum() wasn't sufficiently careful about checking that nested lists represent a rectangular array structure; it would accept inputs such as "[1, []]". This is a bit related to the PL/Python bug fixed in commit 81eaaf65e, but it doesn't seem to provide any direct route to a memory stomp. Instead the likely failure mode is for makeMdArrayResult to be passed fewer Datums than the claimed array dimensionality requires, possibly leading to a wild pointer dereference and SIGSEGV. Per report from Alexander Lakhin. It's been broken for a long time, so back-patch to all supported branches. Discussion: https://postgr.es/m/5ebae5e4-d401-fadf-8585-ac3eaf53219c@gmail.com
2023-04-29 19:06:44 +02:00
*
* The ArrayBuildState is created only when we first find a scalar element;
* if we didn't do it like that, we'd need some other convention for knowing
* whether we'd already found any scalars (and thus the number of dimensions
* is frozen).
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
*/
Support arrays as input to array_agg() and ARRAY(SELECT ...). These cases formerly failed with errors about "could not find array type for data type". Now they yield arrays of the same element type and one higher dimension. The implementation involves creating functions with API similar to the existing accumArrayResult() family. I (tgl) also extended the base family by adding an initArrayResult() function, which allows callers to avoid special-casing the zero-inputs case if they just want an empty array as result. (Not all do, so the previous calling convention remains valid.) This allowed simplifying some existing code in xml.c and plperl.c. Ali Akbar, reviewed by Pavel Stehule, significantly modified by me
2014-11-25 18:21:22 +01:00
static void
Tighten array dimensionality checks in Perl -> SQL array conversion. plperl_array_to_datum() wasn't sufficiently careful about checking that nested lists represent a rectangular array structure; it would accept inputs such as "[1, []]". This is a bit related to the PL/Python bug fixed in commit 81eaaf65e, but it doesn't seem to provide any direct route to a memory stomp. Instead the likely failure mode is for makeMdArrayResult to be passed fewer Datums than the claimed array dimensionality requires, possibly leading to a wild pointer dereference and SIGSEGV. Per report from Alexander Lakhin. It's been broken for a long time, so back-patch to all supported branches. Discussion: https://postgr.es/m/5ebae5e4-d401-fadf-8585-ac3eaf53219c@gmail.com
2023-04-29 19:06:44 +02:00
array_to_datum_internal(AV *av, ArrayBuildState **astatep,
Fix up Perl-to-Postgres datatype conversions in pl/perl. This patch restores the pre-9.1 behavior that pl/perl functions returning VOID ignore the result value of their last Perl statement. 9.1.0 unintentionally threw an error if the last statement returned a reference, as reported by Amit Khandekar. Also, make sure it works to return a string value for a composite type, so long as the string meets the type's input format. We already allowed the equivalent behavior for arrays, so it seems inconsistent to not allow it for composites. In addition, ensure we throw errors for attempts to return arrays or hashes when the function's declared result type is not an array or composite type, respectively. Pre-9.1 versions rather uselessly returned strings like ARRAY(0x221a9a0) or HASH(0x221aa90), while 9.1.0 threw an error for the hash case and returned a garbage value for the array case. Also, clean up assorted grotty coding in Perl array conversion, including use of a session-lifespan memory context to accumulate the array value (resulting in session-lifespan memory leak on error), failure to apply the declared typmod if any, and failure to detect some cases of non-rectangular multi-dimensional arrays. Alex Hunsaker and Tom Lane
2011-10-14 00:02:43 +02:00
int *ndims, int *dims, int cur_depth,
Tighten array dimensionality checks in Perl -> SQL array conversion. plperl_array_to_datum() wasn't sufficiently careful about checking that nested lists represent a rectangular array structure; it would accept inputs such as "[1, []]". This is a bit related to the PL/Python bug fixed in commit 81eaaf65e, but it doesn't seem to provide any direct route to a memory stomp. Instead the likely failure mode is for makeMdArrayResult to be passed fewer Datums than the claimed array dimensionality requires, possibly leading to a wild pointer dereference and SIGSEGV. Per report from Alexander Lakhin. It's been broken for a long time, so back-patch to all supported branches. Discussion: https://postgr.es/m/5ebae5e4-d401-fadf-8585-ac3eaf53219c@gmail.com
2023-04-29 19:06:44 +02:00
Oid elemtypid, int32 typmod,
Fix up Perl-to-Postgres datatype conversions in pl/perl. This patch restores the pre-9.1 behavior that pl/perl functions returning VOID ignore the result value of their last Perl statement. 9.1.0 unintentionally threw an error if the last statement returned a reference, as reported by Amit Khandekar. Also, make sure it works to return a string value for a composite type, so long as the string meets the type's input format. We already allowed the equivalent behavior for arrays, so it seems inconsistent to not allow it for composites. In addition, ensure we throw errors for attempts to return arrays or hashes when the function's declared result type is not an array or composite type, respectively. Pre-9.1 versions rather uselessly returned strings like ARRAY(0x221a9a0) or HASH(0x221aa90), while 9.1.0 threw an error for the hash case and returned a garbage value for the array case. Also, clean up assorted grotty coding in Perl array conversion, including use of a session-lifespan memory context to accumulate the array value (resulting in session-lifespan memory leak on error), failure to apply the declared typmod if any, and failure to detect some cases of non-rectangular multi-dimensional arrays. Alex Hunsaker and Tom Lane
2011-10-14 00:02:43 +02:00
FmgrInfo *finfo, Oid typioparam)
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
{
PL/Perl portability fix: avoid including XSUB.h in plperl.c. In Perl builds that define PERL_IMPLICIT_SYS, XSUB.h defines macros that replace a whole lot of basic libc functions with Perl functions. We can't tolerate that in plperl.c; it breaks at least PG_TRY and probably other stuff. The core idea of this patch is to include XSUB.h only in the .xs files where it's really needed, and to move any code broken by PERL_IMPLICIT_SYS out of the .xs files and into plperl.c. The reason this hasn't been a problem before is that our build techniques did not result in PERL_IMPLICIT_SYS appearing as a #define in PL/Perl, even on some platforms where Perl thinks it is defined. That's about to change in order to fix a nasty portability issue, so we need this work to make the code safe for that. Rather unaccountably, the Perl people chose XSUB.h as the place to provide the versions of the aTHX/aTHX_ macros that are needed by code that's not explicitly aware of the MULTIPLICITY API conventions. Hence, just removing XSUB.h from plperl.c fails miserably. But we can work around that by defining PERL_NO_GET_CONTEXT (which would make the relevant stanza of XSUB.h a no-op anyway). As explained in perlguts.pod, that means we need to add a "dTHX" macro call in every C function that calls a Perl API function. In most of them we just add this at the top; but since the macro fetches the current Perl interpreter pointer, more care is needed in functions that switch the active interpreter. Lack of the macro is easily recognized since it results in bleats about "my_perl" not being defined. (A nice side benefit of this is that it significantly reduces the number of fetches of the current interpreter pointer. On my machine, plperl.so gets more than 10% smaller, and there's probably some performance win too. We could reduce the number of fetches still more by decorating the code with pTHX_/aTHX_ macros to pass the interpreter pointer around, as explained by perlguts.pod; but that's a task for another day.) Formatting note: pgindent seems happy to treat "dTHX;" as a declaration so long as it's the first thing after the left brace, as we'd already observed with respect to the similar macro "dSP;". If you try to put it later in a set of declarations, pgindent puts ugly extra space around it. Having removed XSUB.h from plperl.c, we need only move the support functions for spi_return_next and util_elog (both of which use PG_TRY) out of the .xs files and into plperl.c. This seems sufficient to avoid the known problems caused by PERL_IMPLICIT_SYS, although we could move more code if additional issues emerge. This will need to be back-patched, but first let's see what the buildfarm makes of it. Patch by me, with some help from Ashutosh Sharma Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
2017-07-28 18:25:43 +02:00
dTHX;
Fix up Perl-to-Postgres datatype conversions in pl/perl. This patch restores the pre-9.1 behavior that pl/perl functions returning VOID ignore the result value of their last Perl statement. 9.1.0 unintentionally threw an error if the last statement returned a reference, as reported by Amit Khandekar. Also, make sure it works to return a string value for a composite type, so long as the string meets the type's input format. We already allowed the equivalent behavior for arrays, so it seems inconsistent to not allow it for composites. In addition, ensure we throw errors for attempts to return arrays or hashes when the function's declared result type is not an array or composite type, respectively. Pre-9.1 versions rather uselessly returned strings like ARRAY(0x221a9a0) or HASH(0x221aa90), while 9.1.0 threw an error for the hash case and returned a garbage value for the array case. Also, clean up assorted grotty coding in Perl array conversion, including use of a session-lifespan memory context to accumulate the array value (resulting in session-lifespan memory leak on error), failure to apply the declared typmod if any, and failure to detect some cases of non-rectangular multi-dimensional arrays. Alex Hunsaker and Tom Lane
2011-10-14 00:02:43 +02:00
int i;
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
int len = av_len(av) + 1;
for (i = 0; i < len; i++)
{
Properly handle empty arrays returned from plperl functions. Bug reported by David Wheeler, fix by Alex Hunsaker.
2011-08-17 17:59:18 +02:00
/* fetch the array element */
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
SV **svp = av_fetch(av, i, FALSE);
Properly handle empty arrays returned from plperl functions. Bug reported by David Wheeler, fix by Alex Hunsaker.
2011-08-17 17:59:18 +02:00
/* see if this element is an array, if so get that */
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
SV *sav = svp ? get_perl_array_ref(*svp) : NULL;
Properly handle empty arrays returned from plperl functions. Bug reported by David Wheeler, fix by Alex Hunsaker.
2011-08-17 17:59:18 +02:00
/* multi-dimensional array? */
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
if (sav)
{
AV *nav = (AV *) SvRV(sav);
Fix up Perl-to-Postgres datatype conversions in pl/perl. This patch restores the pre-9.1 behavior that pl/perl functions returning VOID ignore the result value of their last Perl statement. 9.1.0 unintentionally threw an error if the last statement returned a reference, as reported by Amit Khandekar. Also, make sure it works to return a string value for a composite type, so long as the string meets the type's input format. We already allowed the equivalent behavior for arrays, so it seems inconsistent to not allow it for composites. In addition, ensure we throw errors for attempts to return arrays or hashes when the function's declared result type is not an array or composite type, respectively. Pre-9.1 versions rather uselessly returned strings like ARRAY(0x221a9a0) or HASH(0x221aa90), while 9.1.0 threw an error for the hash case and returned a garbage value for the array case. Also, clean up assorted grotty coding in Perl array conversion, including use of a session-lifespan memory context to accumulate the array value (resulting in session-lifespan memory leak on error), failure to apply the declared typmod if any, and failure to detect some cases of non-rectangular multi-dimensional arrays. Alex Hunsaker and Tom Lane
2011-10-14 00:02:43 +02:00
/* set size when at first element in this level, else compare */
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
if (i == 0 && *ndims == cur_depth)
{
Tighten array dimensionality checks in Perl -> SQL array conversion. plperl_array_to_datum() wasn't sufficiently careful about checking that nested lists represent a rectangular array structure; it would accept inputs such as "[1, []]". This is a bit related to the PL/Python bug fixed in commit 81eaaf65e, but it doesn't seem to provide any direct route to a memory stomp. Instead the likely failure mode is for makeMdArrayResult to be passed fewer Datums than the claimed array dimensionality requires, possibly leading to a wild pointer dereference and SIGSEGV. Per report from Alexander Lakhin. It's been broken for a long time, so back-patch to all supported branches. Discussion: https://postgr.es/m/5ebae5e4-d401-fadf-8585-ac3eaf53219c@gmail.com
2023-04-29 19:06:44 +02:00
/* array after some scalars at same level? */
if (*astatep != NULL)
ereport(ERROR,
(errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
errmsg("multidimensional arrays must have array expressions with matching dimensions")));
/* too many dimensions? */
if (cur_depth + 1 > MAXDIM)
ereport(ERROR,
(errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED),
errmsg("number of array dimensions (%d) exceeds the maximum allowed (%d)",
cur_depth + 1, MAXDIM)));
/* OK, add a dimension */
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
dims[*ndims] = av_len(nav) + 1;
(*ndims)++;
}
Tighten array dimensionality checks in Perl -> SQL array conversion. plperl_array_to_datum() wasn't sufficiently careful about checking that nested lists represent a rectangular array structure; it would accept inputs such as "[1, []]". This is a bit related to the PL/Python bug fixed in commit 81eaaf65e, but it doesn't seem to provide any direct route to a memory stomp. Instead the likely failure mode is for makeMdArrayResult to be passed fewer Datums than the claimed array dimensionality requires, possibly leading to a wild pointer dereference and SIGSEGV. Per report from Alexander Lakhin. It's been broken for a long time, so back-patch to all supported branches. Discussion: https://postgr.es/m/5ebae5e4-d401-fadf-8585-ac3eaf53219c@gmail.com
2023-04-29 19:06:44 +02:00
else if (cur_depth >= *ndims ||
av_len(nav) + 1 != dims[cur_depth])
Fix up Perl-to-Postgres datatype conversions in pl/perl. This patch restores the pre-9.1 behavior that pl/perl functions returning VOID ignore the result value of their last Perl statement. 9.1.0 unintentionally threw an error if the last statement returned a reference, as reported by Amit Khandekar. Also, make sure it works to return a string value for a composite type, so long as the string meets the type's input format. We already allowed the equivalent behavior for arrays, so it seems inconsistent to not allow it for composites. In addition, ensure we throw errors for attempts to return arrays or hashes when the function's declared result type is not an array or composite type, respectively. Pre-9.1 versions rather uselessly returned strings like ARRAY(0x221a9a0) or HASH(0x221aa90), while 9.1.0 threw an error for the hash case and returned a garbage value for the array case. Also, clean up assorted grotty coding in Perl array conversion, including use of a session-lifespan memory context to accumulate the array value (resulting in session-lifespan memory leak on error), failure to apply the declared typmod if any, and failure to detect some cases of non-rectangular multi-dimensional arrays. Alex Hunsaker and Tom Lane
2011-10-14 00:02:43 +02:00
ereport(ERROR,
(errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
errmsg("multidimensional arrays must have array expressions with matching dimensions")));
/* recurse to fetch elements of this sub-array */
Tighten array dimensionality checks in Perl -> SQL array conversion. plperl_array_to_datum() wasn't sufficiently careful about checking that nested lists represent a rectangular array structure; it would accept inputs such as "[1, []]". This is a bit related to the PL/Python bug fixed in commit 81eaaf65e, but it doesn't seem to provide any direct route to a memory stomp. Instead the likely failure mode is for makeMdArrayResult to be passed fewer Datums than the claimed array dimensionality requires, possibly leading to a wild pointer dereference and SIGSEGV. Per report from Alexander Lakhin. It's been broken for a long time, so back-patch to all supported branches. Discussion: https://postgr.es/m/5ebae5e4-d401-fadf-8585-ac3eaf53219c@gmail.com
2023-04-29 19:06:44 +02:00
array_to_datum_internal(nav, astatep,
Support arrays as input to array_agg() and ARRAY(SELECT ...). These cases formerly failed with errors about "could not find array type for data type". Now they yield arrays of the same element type and one higher dimension. The implementation involves creating functions with API similar to the existing accumArrayResult() family. I (tgl) also extended the base family by adding an initArrayResult() function, which allows callers to avoid special-casing the zero-inputs case if they just want an empty array as result. (Not all do, so the previous calling convention remains valid.) This allowed simplifying some existing code in xml.c and plperl.c. Ali Akbar, reviewed by Pavel Stehule, significantly modified by me
2014-11-25 18:21:22 +01:00
ndims, dims, cur_depth + 1,
Tighten array dimensionality checks in Perl -> SQL array conversion. plperl_array_to_datum() wasn't sufficiently careful about checking that nested lists represent a rectangular array structure; it would accept inputs such as "[1, []]". This is a bit related to the PL/Python bug fixed in commit 81eaaf65e, but it doesn't seem to provide any direct route to a memory stomp. Instead the likely failure mode is for makeMdArrayResult to be passed fewer Datums than the claimed array dimensionality requires, possibly leading to a wild pointer dereference and SIGSEGV. Per report from Alexander Lakhin. It's been broken for a long time, so back-patch to all supported branches. Discussion: https://postgr.es/m/5ebae5e4-d401-fadf-8585-ac3eaf53219c@gmail.com
2023-04-29 19:06:44 +02:00
elemtypid, typmod,
Support arrays as input to array_agg() and ARRAY(SELECT ...). These cases formerly failed with errors about "could not find array type for data type". Now they yield arrays of the same element type and one higher dimension. The implementation involves creating functions with API similar to the existing accumArrayResult() family. I (tgl) also extended the base family by adding an initArrayResult() function, which allows callers to avoid special-casing the zero-inputs case if they just want an empty array as result. (Not all do, so the previous calling convention remains valid.) This allowed simplifying some existing code in xml.c and plperl.c. Ali Akbar, reviewed by Pavel Stehule, significantly modified by me
2014-11-25 18:21:22 +01:00
finfo, typioparam);
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
}
else
{
Fix up Perl-to-Postgres datatype conversions in pl/perl. This patch restores the pre-9.1 behavior that pl/perl functions returning VOID ignore the result value of their last Perl statement. 9.1.0 unintentionally threw an error if the last statement returned a reference, as reported by Amit Khandekar. Also, make sure it works to return a string value for a composite type, so long as the string meets the type's input format. We already allowed the equivalent behavior for arrays, so it seems inconsistent to not allow it for composites. In addition, ensure we throw errors for attempts to return arrays or hashes when the function's declared result type is not an array or composite type, respectively. Pre-9.1 versions rather uselessly returned strings like ARRAY(0x221a9a0) or HASH(0x221aa90), while 9.1.0 threw an error for the hash case and returned a garbage value for the array case. Also, clean up assorted grotty coding in Perl array conversion, including use of a session-lifespan memory context to accumulate the array value (resulting in session-lifespan memory leak on error), failure to apply the declared typmod if any, and failure to detect some cases of non-rectangular multi-dimensional arrays. Alex Hunsaker and Tom Lane
2011-10-14 00:02:43 +02:00
Datum dat;
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
bool isnull;
Fix up Perl-to-Postgres datatype conversions in pl/perl. This patch restores the pre-9.1 behavior that pl/perl functions returning VOID ignore the result value of their last Perl statement. 9.1.0 unintentionally threw an error if the last statement returned a reference, as reported by Amit Khandekar. Also, make sure it works to return a string value for a composite type, so long as the string meets the type's input format. We already allowed the equivalent behavior for arrays, so it seems inconsistent to not allow it for composites. In addition, ensure we throw errors for attempts to return arrays or hashes when the function's declared result type is not an array or composite type, respectively. Pre-9.1 versions rather uselessly returned strings like ARRAY(0x221a9a0) or HASH(0x221aa90), while 9.1.0 threw an error for the hash case and returned a garbage value for the array case. Also, clean up assorted grotty coding in Perl array conversion, including use of a session-lifespan memory context to accumulate the array value (resulting in session-lifespan memory leak on error), failure to apply the declared typmod if any, and failure to detect some cases of non-rectangular multi-dimensional arrays. Alex Hunsaker and Tom Lane
2011-10-14 00:02:43 +02:00
/* scalar after some sub-arrays at same level? */
if (*ndims != cur_depth)
ereport(ERROR,
(errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
errmsg("multidimensional arrays must have array expressions with matching dimensions")));
dat = plperl_sv_to_datum(svp ? *svp : NULL,
elemtypid,
typmod,
NULL,
finfo,
typioparam,
&isnull);
Tighten array dimensionality checks in Perl -> SQL array conversion. plperl_array_to_datum() wasn't sufficiently careful about checking that nested lists represent a rectangular array structure; it would accept inputs such as "[1, []]". This is a bit related to the PL/Python bug fixed in commit 81eaaf65e, but it doesn't seem to provide any direct route to a memory stomp. Instead the likely failure mode is for makeMdArrayResult to be passed fewer Datums than the claimed array dimensionality requires, possibly leading to a wild pointer dereference and SIGSEGV. Per report from Alexander Lakhin. It's been broken for a long time, so back-patch to all supported branches. Discussion: https://postgr.es/m/5ebae5e4-d401-fadf-8585-ac3eaf53219c@gmail.com
2023-04-29 19:06:44 +02:00
/* Create ArrayBuildState if we didn't already */
if (*astatep == NULL)
*astatep = initArrayResult(elemtypid,
CurrentMemoryContext, true);
/* ... and save the element value in it */
(void) accumArrayResult(*astatep, dat, isnull,
Support arrays as input to array_agg() and ARRAY(SELECT ...). These cases formerly failed with errors about "could not find array type for data type". Now they yield arrays of the same element type and one higher dimension. The implementation involves creating functions with API similar to the existing accumArrayResult() family. I (tgl) also extended the base family by adding an initArrayResult() function, which allows callers to avoid special-casing the zero-inputs case if they just want an empty array as result. (Not all do, so the previous calling convention remains valid.) This allowed simplifying some existing code in xml.c and plperl.c. Ali Akbar, reviewed by Pavel Stehule, significantly modified by me
2014-11-25 18:21:22 +01:00
elemtypid, CurrentMemoryContext);
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
}
}
}
/*
* convert perl array ref to a datum
*/
static Datum
Fix up Perl-to-Postgres datatype conversions in pl/perl. This patch restores the pre-9.1 behavior that pl/perl functions returning VOID ignore the result value of their last Perl statement. 9.1.0 unintentionally threw an error if the last statement returned a reference, as reported by Amit Khandekar. Also, make sure it works to return a string value for a composite type, so long as the string meets the type's input format. We already allowed the equivalent behavior for arrays, so it seems inconsistent to not allow it for composites. In addition, ensure we throw errors for attempts to return arrays or hashes when the function's declared result type is not an array or composite type, respectively. Pre-9.1 versions rather uselessly returned strings like ARRAY(0x221a9a0) or HASH(0x221aa90), while 9.1.0 threw an error for the hash case and returned a garbage value for the array case. Also, clean up assorted grotty coding in Perl array conversion, including use of a session-lifespan memory context to accumulate the array value (resulting in session-lifespan memory leak on error), failure to apply the declared typmod if any, and failure to detect some cases of non-rectangular multi-dimensional arrays. Alex Hunsaker and Tom Lane
2011-10-14 00:02:43 +02:00
plperl_array_to_datum(SV *src, Oid typid, int32 typmod)
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
{
PL/Perl portability fix: avoid including XSUB.h in plperl.c. In Perl builds that define PERL_IMPLICIT_SYS, XSUB.h defines macros that replace a whole lot of basic libc functions with Perl functions. We can't tolerate that in plperl.c; it breaks at least PG_TRY and probably other stuff. The core idea of this patch is to include XSUB.h only in the .xs files where it's really needed, and to move any code broken by PERL_IMPLICIT_SYS out of the .xs files and into plperl.c. The reason this hasn't been a problem before is that our build techniques did not result in PERL_IMPLICIT_SYS appearing as a #define in PL/Perl, even on some platforms where Perl thinks it is defined. That's about to change in order to fix a nasty portability issue, so we need this work to make the code safe for that. Rather unaccountably, the Perl people chose XSUB.h as the place to provide the versions of the aTHX/aTHX_ macros that are needed by code that's not explicitly aware of the MULTIPLICITY API conventions. Hence, just removing XSUB.h from plperl.c fails miserably. But we can work around that by defining PERL_NO_GET_CONTEXT (which would make the relevant stanza of XSUB.h a no-op anyway). As explained in perlguts.pod, that means we need to add a "dTHX" macro call in every C function that calls a Perl API function. In most of them we just add this at the top; but since the macro fetches the current Perl interpreter pointer, more care is needed in functions that switch the active interpreter. Lack of the macro is easily recognized since it results in bleats about "my_perl" not being defined. (A nice side benefit of this is that it significantly reduces the number of fetches of the current interpreter pointer. On my machine, plperl.so gets more than 10% smaller, and there's probably some performance win too. We could reduce the number of fetches still more by decorating the code with pTHX_/aTHX_ macros to pass the interpreter pointer around, as explained by perlguts.pod; but that's a task for another day.) Formatting note: pgindent seems happy to treat "dTHX;" as a declaration so long as it's the first thing after the left brace, as we'd already observed with respect to the similar macro "dSP;". If you try to put it later in a set of declarations, pgindent puts ugly extra space around it. Having removed XSUB.h from plperl.c, we need only move the support functions for spi_return_next and util_elog (both of which use PG_TRY) out of the .xs files and into plperl.c. This seems sufficient to avoid the known problems caused by PERL_IMPLICIT_SYS, although we could move more code if additional issues emerge. This will need to be back-patched, but first let's see what the buildfarm makes of it. Patch by me, with some help from Ashutosh Sharma Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
2017-07-28 18:25:43 +02:00
dTHX;
Tighten array dimensionality checks in Perl -> SQL array conversion. plperl_array_to_datum() wasn't sufficiently careful about checking that nested lists represent a rectangular array structure; it would accept inputs such as "[1, []]". This is a bit related to the PL/Python bug fixed in commit 81eaaf65e, but it doesn't seem to provide any direct route to a memory stomp. Instead the likely failure mode is for makeMdArrayResult to be passed fewer Datums than the claimed array dimensionality requires, possibly leading to a wild pointer dereference and SIGSEGV. Per report from Alexander Lakhin. It's been broken for a long time, so back-patch to all supported branches. Discussion: https://postgr.es/m/5ebae5e4-d401-fadf-8585-ac3eaf53219c@gmail.com
2023-04-29 19:06:44 +02:00
AV *nav = (AV *) SvRV(src);
ArrayBuildState *astate = NULL;
Fix up Perl-to-Postgres datatype conversions in pl/perl. This patch restores the pre-9.1 behavior that pl/perl functions returning VOID ignore the result value of their last Perl statement. 9.1.0 unintentionally threw an error if the last statement returned a reference, as reported by Amit Khandekar. Also, make sure it works to return a string value for a composite type, so long as the string meets the type's input format. We already allowed the equivalent behavior for arrays, so it seems inconsistent to not allow it for composites. In addition, ensure we throw errors for attempts to return arrays or hashes when the function's declared result type is not an array or composite type, respectively. Pre-9.1 versions rather uselessly returned strings like ARRAY(0x221a9a0) or HASH(0x221aa90), while 9.1.0 threw an error for the hash case and returned a garbage value for the array case. Also, clean up assorted grotty coding in Perl array conversion, including use of a session-lifespan memory context to accumulate the array value (resulting in session-lifespan memory leak on error), failure to apply the declared typmod if any, and failure to detect some cases of non-rectangular multi-dimensional arrays. Alex Hunsaker and Tom Lane
2011-10-14 00:02:43 +02:00
Oid elemtypid;
FmgrInfo finfo;
Oid typioparam;
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
int dims[MAXDIM];
int lbs[MAXDIM];
int ndims = 1;
int i;
Fix up Perl-to-Postgres datatype conversions in pl/perl. This patch restores the pre-9.1 behavior that pl/perl functions returning VOID ignore the result value of their last Perl statement. 9.1.0 unintentionally threw an error if the last statement returned a reference, as reported by Amit Khandekar. Also, make sure it works to return a string value for a composite type, so long as the string meets the type's input format. We already allowed the equivalent behavior for arrays, so it seems inconsistent to not allow it for composites. In addition, ensure we throw errors for attempts to return arrays or hashes when the function's declared result type is not an array or composite type, respectively. Pre-9.1 versions rather uselessly returned strings like ARRAY(0x221a9a0) or HASH(0x221aa90), while 9.1.0 threw an error for the hash case and returned a garbage value for the array case. Also, clean up assorted grotty coding in Perl array conversion, including use of a session-lifespan memory context to accumulate the array value (resulting in session-lifespan memory leak on error), failure to apply the declared typmod if any, and failure to detect some cases of non-rectangular multi-dimensional arrays. Alex Hunsaker and Tom Lane
2011-10-14 00:02:43 +02:00
elemtypid = get_element_type(typid);
if (!elemtypid)
ereport(ERROR,
(errcode(ERRCODE_DATATYPE_MISMATCH),
errmsg("cannot convert Perl array to non-array type %s",
format_type_be(typid))));
_sv_to_datum_finfo(elemtypid, &finfo, &typioparam);
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
memset(dims, 0, sizeof(dims));
Tighten array dimensionality checks in Perl -> SQL array conversion. plperl_array_to_datum() wasn't sufficiently careful about checking that nested lists represent a rectangular array structure; it would accept inputs such as "[1, []]". This is a bit related to the PL/Python bug fixed in commit 81eaaf65e, but it doesn't seem to provide any direct route to a memory stomp. Instead the likely failure mode is for makeMdArrayResult to be passed fewer Datums than the claimed array dimensionality requires, possibly leading to a wild pointer dereference and SIGSEGV. Per report from Alexander Lakhin. It's been broken for a long time, so back-patch to all supported branches. Discussion: https://postgr.es/m/5ebae5e4-d401-fadf-8585-ac3eaf53219c@gmail.com
2023-04-29 19:06:44 +02:00
dims[0] = av_len(nav) + 1;
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
Tighten array dimensionality checks in Perl -> SQL array conversion. plperl_array_to_datum() wasn't sufficiently careful about checking that nested lists represent a rectangular array structure; it would accept inputs such as "[1, []]". This is a bit related to the PL/Python bug fixed in commit 81eaaf65e, but it doesn't seem to provide any direct route to a memory stomp. Instead the likely failure mode is for makeMdArrayResult to be passed fewer Datums than the claimed array dimensionality requires, possibly leading to a wild pointer dereference and SIGSEGV. Per report from Alexander Lakhin. It's been broken for a long time, so back-patch to all supported branches. Discussion: https://postgr.es/m/5ebae5e4-d401-fadf-8585-ac3eaf53219c@gmail.com
2023-04-29 19:06:44 +02:00
array_to_datum_internal(nav, &astate,
Support arrays as input to array_agg() and ARRAY(SELECT ...). These cases formerly failed with errors about "could not find array type for data type". Now they yield arrays of the same element type and one higher dimension. The implementation involves creating functions with API similar to the existing accumArrayResult() family. I (tgl) also extended the base family by adding an initArrayResult() function, which allows callers to avoid special-casing the zero-inputs case if they just want an empty array as result. (Not all do, so the previous calling convention remains valid.) This allowed simplifying some existing code in xml.c and plperl.c. Ali Akbar, reviewed by Pavel Stehule, significantly modified by me
2014-11-25 18:21:22 +01:00
&ndims, dims, 1,
Tighten array dimensionality checks in Perl -> SQL array conversion. plperl_array_to_datum() wasn't sufficiently careful about checking that nested lists represent a rectangular array structure; it would accept inputs such as "[1, []]". This is a bit related to the PL/Python bug fixed in commit 81eaaf65e, but it doesn't seem to provide any direct route to a memory stomp. Instead the likely failure mode is for makeMdArrayResult to be passed fewer Datums than the claimed array dimensionality requires, possibly leading to a wild pointer dereference and SIGSEGV. Per report from Alexander Lakhin. It's been broken for a long time, so back-patch to all supported branches. Discussion: https://postgr.es/m/5ebae5e4-d401-fadf-8585-ac3eaf53219c@gmail.com
2023-04-29 19:06:44 +02:00
elemtypid, typmod,
Support arrays as input to array_agg() and ARRAY(SELECT ...). These cases formerly failed with errors about "could not find array type for data type". Now they yield arrays of the same element type and one higher dimension. The implementation involves creating functions with API similar to the existing accumArrayResult() family. I (tgl) also extended the base family by adding an initArrayResult() function, which allows callers to avoid special-casing the zero-inputs case if they just want an empty array as result. (Not all do, so the previous calling convention remains valid.) This allowed simplifying some existing code in xml.c and plperl.c. Ali Akbar, reviewed by Pavel Stehule, significantly modified by me
2014-11-25 18:21:22 +01:00
&finfo, typioparam);
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
Support arrays as input to array_agg() and ARRAY(SELECT ...). These cases formerly failed with errors about "could not find array type for data type". Now they yield arrays of the same element type and one higher dimension. The implementation involves creating functions with API similar to the existing accumArrayResult() family. I (tgl) also extended the base family by adding an initArrayResult() function, which allows callers to avoid special-casing the zero-inputs case if they just want an empty array as result. (Not all do, so the previous calling convention remains valid.) This allowed simplifying some existing code in xml.c and plperl.c. Ali Akbar, reviewed by Pavel Stehule, significantly modified by me
2014-11-25 18:21:22 +01:00
/* ensure we get zero-D array for no inputs, as per PG convention */
Tighten array dimensionality checks in Perl -> SQL array conversion. plperl_array_to_datum() wasn't sufficiently careful about checking that nested lists represent a rectangular array structure; it would accept inputs such as "[1, []]". This is a bit related to the PL/Python bug fixed in commit 81eaaf65e, but it doesn't seem to provide any direct route to a memory stomp. Instead the likely failure mode is for makeMdArrayResult to be passed fewer Datums than the claimed array dimensionality requires, possibly leading to a wild pointer dereference and SIGSEGV. Per report from Alexander Lakhin. It's been broken for a long time, so back-patch to all supported branches. Discussion: https://postgr.es/m/5ebae5e4-d401-fadf-8585-ac3eaf53219c@gmail.com
2023-04-29 19:06:44 +02:00
if (astate == NULL)
return PointerGetDatum(construct_empty_array(elemtypid));
Properly handle empty arrays returned from plperl functions. Bug reported by David Wheeler, fix by Alex Hunsaker.
2011-08-17 17:59:18 +02:00
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
for (i = 0; i < ndims; i++)
lbs[i] = 1;
Fix up Perl-to-Postgres datatype conversions in pl/perl. This patch restores the pre-9.1 behavior that pl/perl functions returning VOID ignore the result value of their last Perl statement. 9.1.0 unintentionally threw an error if the last statement returned a reference, as reported by Amit Khandekar. Also, make sure it works to return a string value for a composite type, so long as the string meets the type's input format. We already allowed the equivalent behavior for arrays, so it seems inconsistent to not allow it for composites. In addition, ensure we throw errors for attempts to return arrays or hashes when the function's declared result type is not an array or composite type, respectively. Pre-9.1 versions rather uselessly returned strings like ARRAY(0x221a9a0) or HASH(0x221aa90), while 9.1.0 threw an error for the hash case and returned a garbage value for the array case. Also, clean up assorted grotty coding in Perl array conversion, including use of a session-lifespan memory context to accumulate the array value (resulting in session-lifespan memory leak on error), failure to apply the declared typmod if any, and failure to detect some cases of non-rectangular multi-dimensional arrays. Alex Hunsaker and Tom Lane
2011-10-14 00:02:43 +02:00
return makeMdArrayResult(astate, ndims, dims, lbs,
CurrentMemoryContext, true);
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
}
Fix up Perl-to-Postgres datatype conversions in pl/perl. This patch restores the pre-9.1 behavior that pl/perl functions returning VOID ignore the result value of their last Perl statement. 9.1.0 unintentionally threw an error if the last statement returned a reference, as reported by Amit Khandekar. Also, make sure it works to return a string value for a composite type, so long as the string meets the type's input format. We already allowed the equivalent behavior for arrays, so it seems inconsistent to not allow it for composites. In addition, ensure we throw errors for attempts to return arrays or hashes when the function's declared result type is not an array or composite type, respectively. Pre-9.1 versions rather uselessly returned strings like ARRAY(0x221a9a0) or HASH(0x221aa90), while 9.1.0 threw an error for the hash case and returned a garbage value for the array case. Also, clean up assorted grotty coding in Perl array conversion, including use of a session-lifespan memory context to accumulate the array value (resulting in session-lifespan memory leak on error), failure to apply the declared typmod if any, and failure to detect some cases of non-rectangular multi-dimensional arrays. Alex Hunsaker and Tom Lane
2011-10-14 00:02:43 +02:00
/* Get the information needed to convert data to the specified PG type */
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
static void
Fix up Perl-to-Postgres datatype conversions in pl/perl. This patch restores the pre-9.1 behavior that pl/perl functions returning VOID ignore the result value of their last Perl statement. 9.1.0 unintentionally threw an error if the last statement returned a reference, as reported by Amit Khandekar. Also, make sure it works to return a string value for a composite type, so long as the string meets the type's input format. We already allowed the equivalent behavior for arrays, so it seems inconsistent to not allow it for composites. In addition, ensure we throw errors for attempts to return arrays or hashes when the function's declared result type is not an array or composite type, respectively. Pre-9.1 versions rather uselessly returned strings like ARRAY(0x221a9a0) or HASH(0x221aa90), while 9.1.0 threw an error for the hash case and returned a garbage value for the array case. Also, clean up assorted grotty coding in Perl array conversion, including use of a session-lifespan memory context to accumulate the array value (resulting in session-lifespan memory leak on error), failure to apply the declared typmod if any, and failure to detect some cases of non-rectangular multi-dimensional arrays. Alex Hunsaker and Tom Lane
2011-10-14 00:02:43 +02:00
_sv_to_datum_finfo(Oid typid, FmgrInfo *finfo, Oid *typioparam)
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
{
Oid typinput;
/* XXX would be better to cache these lookups */
getTypeInputInfo(typid,
&typinput, typioparam);
Fix up Perl-to-Postgres datatype conversions in pl/perl. This patch restores the pre-9.1 behavior that pl/perl functions returning VOID ignore the result value of their last Perl statement. 9.1.0 unintentionally threw an error if the last statement returned a reference, as reported by Amit Khandekar. Also, make sure it works to return a string value for a composite type, so long as the string meets the type's input format. We already allowed the equivalent behavior for arrays, so it seems inconsistent to not allow it for composites. In addition, ensure we throw errors for attempts to return arrays or hashes when the function's declared result type is not an array or composite type, respectively. Pre-9.1 versions rather uselessly returned strings like ARRAY(0x221a9a0) or HASH(0x221aa90), while 9.1.0 threw an error for the hash case and returned a garbage value for the array case. Also, clean up assorted grotty coding in Perl array conversion, including use of a session-lifespan memory context to accumulate the array value (resulting in session-lifespan memory leak on error), failure to apply the declared typmod if any, and failure to detect some cases of non-rectangular multi-dimensional arrays. Alex Hunsaker and Tom Lane
2011-10-14 00:02:43 +02:00
fmgr_info(typinput, finfo);
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
}
/*
Fix up Perl-to-Postgres datatype conversions in pl/perl. This patch restores the pre-9.1 behavior that pl/perl functions returning VOID ignore the result value of their last Perl statement. 9.1.0 unintentionally threw an error if the last statement returned a reference, as reported by Amit Khandekar. Also, make sure it works to return a string value for a composite type, so long as the string meets the type's input format. We already allowed the equivalent behavior for arrays, so it seems inconsistent to not allow it for composites. In addition, ensure we throw errors for attempts to return arrays or hashes when the function's declared result type is not an array or composite type, respectively. Pre-9.1 versions rather uselessly returned strings like ARRAY(0x221a9a0) or HASH(0x221aa90), while 9.1.0 threw an error for the hash case and returned a garbage value for the array case. Also, clean up assorted grotty coding in Perl array conversion, including use of a session-lifespan memory context to accumulate the array value (resulting in session-lifespan memory leak on error), failure to apply the declared typmod if any, and failure to detect some cases of non-rectangular multi-dimensional arrays. Alex Hunsaker and Tom Lane
2011-10-14 00:02:43 +02:00
* convert Perl SV to PG datum of type typid, typmod typmod
*
* Pass the PL/Perl function's fcinfo when attempting to convert to the
* function's result type; otherwise pass NULL. This is used when we need to
* resolve the actual result type of a function returning RECORD.
*
* finfo and typioparam should be the results of _sv_to_datum_finfo for the
* given typid, or NULL/InvalidOid to let this function do the lookups.
*
* *isnull is an output parameter.
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
*/
static Datum
Fix up Perl-to-Postgres datatype conversions in pl/perl. This patch restores the pre-9.1 behavior that pl/perl functions returning VOID ignore the result value of their last Perl statement. 9.1.0 unintentionally threw an error if the last statement returned a reference, as reported by Amit Khandekar. Also, make sure it works to return a string value for a composite type, so long as the string meets the type's input format. We already allowed the equivalent behavior for arrays, so it seems inconsistent to not allow it for composites. In addition, ensure we throw errors for attempts to return arrays or hashes when the function's declared result type is not an array or composite type, respectively. Pre-9.1 versions rather uselessly returned strings like ARRAY(0x221a9a0) or HASH(0x221aa90), while 9.1.0 threw an error for the hash case and returned a garbage value for the array case. Also, clean up assorted grotty coding in Perl array conversion, including use of a session-lifespan memory context to accumulate the array value (resulting in session-lifespan memory leak on error), failure to apply the declared typmod if any, and failure to detect some cases of non-rectangular multi-dimensional arrays. Alex Hunsaker and Tom Lane
2011-10-14 00:02:43 +02:00
plperl_sv_to_datum(SV *sv, Oid typid, int32 typmod,
FunctionCallInfo fcinfo,
FmgrInfo *finfo, Oid typioparam,
bool *isnull)
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
{
FmgrInfo tmp;
Add transforms feature This provides a mechanism for specifying conversions between SQL data types and procedural languages. As examples, there are transforms for hstore and ltree for PL/Perl and PL/Python. reviews by Pavel Stěhule and Andres Freund
2015-04-26 16:33:14 +02:00
Oid funcid;
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
/* we might recurse */
check_stack_depth();
Fix up Perl-to-Postgres datatype conversions in pl/perl. This patch restores the pre-9.1 behavior that pl/perl functions returning VOID ignore the result value of their last Perl statement. 9.1.0 unintentionally threw an error if the last statement returned a reference, as reported by Amit Khandekar. Also, make sure it works to return a string value for a composite type, so long as the string meets the type's input format. We already allowed the equivalent behavior for arrays, so it seems inconsistent to not allow it for composites. In addition, ensure we throw errors for attempts to return arrays or hashes when the function's declared result type is not an array or composite type, respectively. Pre-9.1 versions rather uselessly returned strings like ARRAY(0x221a9a0) or HASH(0x221aa90), while 9.1.0 threw an error for the hash case and returned a garbage value for the array case. Also, clean up assorted grotty coding in Perl array conversion, including use of a session-lifespan memory context to accumulate the array value (resulting in session-lifespan memory leak on error), failure to apply the declared typmod if any, and failure to detect some cases of non-rectangular multi-dimensional arrays. Alex Hunsaker and Tom Lane
2011-10-14 00:02:43 +02:00
*isnull = false;
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
Fix up Perl-to-Postgres datatype conversions in pl/perl. This patch restores the pre-9.1 behavior that pl/perl functions returning VOID ignore the result value of their last Perl statement. 9.1.0 unintentionally threw an error if the last statement returned a reference, as reported by Amit Khandekar. Also, make sure it works to return a string value for a composite type, so long as the string meets the type's input format. We already allowed the equivalent behavior for arrays, so it seems inconsistent to not allow it for composites. In addition, ensure we throw errors for attempts to return arrays or hashes when the function's declared result type is not an array or composite type, respectively. Pre-9.1 versions rather uselessly returned strings like ARRAY(0x221a9a0) or HASH(0x221aa90), while 9.1.0 threw an error for the hash case and returned a garbage value for the array case. Also, clean up assorted grotty coding in Perl array conversion, including use of a session-lifespan memory context to accumulate the array value (resulting in session-lifespan memory leak on error), failure to apply the declared typmod if any, and failure to detect some cases of non-rectangular multi-dimensional arrays. Alex Hunsaker and Tom Lane
2011-10-14 00:02:43 +02:00
/*
* Return NULL if result is undef, or if we're in a function returning
* VOID. In the latter case, we should pay no attention to the last Perl
* statement's result, and this is a convenient means to ensure that.
*/
if (!sv || !SvOK(sv) || typid == VOIDOID)
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
{
Fix up Perl-to-Postgres datatype conversions in pl/perl. This patch restores the pre-9.1 behavior that pl/perl functions returning VOID ignore the result value of their last Perl statement. 9.1.0 unintentionally threw an error if the last statement returned a reference, as reported by Amit Khandekar. Also, make sure it works to return a string value for a composite type, so long as the string meets the type's input format. We already allowed the equivalent behavior for arrays, so it seems inconsistent to not allow it for composites. In addition, ensure we throw errors for attempts to return arrays or hashes when the function's declared result type is not an array or composite type, respectively. Pre-9.1 versions rather uselessly returned strings like ARRAY(0x221a9a0) or HASH(0x221aa90), while 9.1.0 threw an error for the hash case and returned a garbage value for the array case. Also, clean up assorted grotty coding in Perl array conversion, including use of a session-lifespan memory context to accumulate the array value (resulting in session-lifespan memory leak on error), failure to apply the declared typmod if any, and failure to detect some cases of non-rectangular multi-dimensional arrays. Alex Hunsaker and Tom Lane
2011-10-14 00:02:43 +02:00
/* look up type info if they did not pass it */
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
if (!finfo)
{
Fix up Perl-to-Postgres datatype conversions in pl/perl. This patch restores the pre-9.1 behavior that pl/perl functions returning VOID ignore the result value of their last Perl statement. 9.1.0 unintentionally threw an error if the last statement returned a reference, as reported by Amit Khandekar. Also, make sure it works to return a string value for a composite type, so long as the string meets the type's input format. We already allowed the equivalent behavior for arrays, so it seems inconsistent to not allow it for composites. In addition, ensure we throw errors for attempts to return arrays or hashes when the function's declared result type is not an array or composite type, respectively. Pre-9.1 versions rather uselessly returned strings like ARRAY(0x221a9a0) or HASH(0x221aa90), while 9.1.0 threw an error for the hash case and returned a garbage value for the array case. Also, clean up assorted grotty coding in Perl array conversion, including use of a session-lifespan memory context to accumulate the array value (resulting in session-lifespan memory leak on error), failure to apply the declared typmod if any, and failure to detect some cases of non-rectangular multi-dimensional arrays. Alex Hunsaker and Tom Lane
2011-10-14 00:02:43 +02:00
_sv_to_datum_finfo(typid, &tmp, &typioparam);
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
finfo = &tmp;
}
Fix up Perl-to-Postgres datatype conversions in pl/perl. This patch restores the pre-9.1 behavior that pl/perl functions returning VOID ignore the result value of their last Perl statement. 9.1.0 unintentionally threw an error if the last statement returned a reference, as reported by Amit Khandekar. Also, make sure it works to return a string value for a composite type, so long as the string meets the type's input format. We already allowed the equivalent behavior for arrays, so it seems inconsistent to not allow it for composites. In addition, ensure we throw errors for attempts to return arrays or hashes when the function's declared result type is not an array or composite type, respectively. Pre-9.1 versions rather uselessly returned strings like ARRAY(0x221a9a0) or HASH(0x221aa90), while 9.1.0 threw an error for the hash case and returned a garbage value for the array case. Also, clean up assorted grotty coding in Perl array conversion, including use of a session-lifespan memory context to accumulate the array value (resulting in session-lifespan memory leak on error), failure to apply the declared typmod if any, and failure to detect some cases of non-rectangular multi-dimensional arrays. Alex Hunsaker and Tom Lane
2011-10-14 00:02:43 +02:00
*isnull = true;
/* must call typinput in case it wants to reject NULL */
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
return InputFunctionCall(finfo, NULL, typioparam, typmod);
}
Add transforms feature This provides a mechanism for specifying conversions between SQL data types and procedural languages. As examples, there are transforms for hstore and ltree for PL/Perl and PL/Python. reviews by Pavel Stěhule and Andres Freund
2015-04-26 16:33:14 +02:00
else if ((funcid = get_transform_tosql(typid, current_call_data->prodesc->lang_oid, current_call_data->prodesc->trftypes)))
return OidFunctionCall1(funcid, PointerGetDatum(sv));
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
else if (SvROK(sv))
{
Fix up Perl-to-Postgres datatype conversions in pl/perl. This patch restores the pre-9.1 behavior that pl/perl functions returning VOID ignore the result value of their last Perl statement. 9.1.0 unintentionally threw an error if the last statement returned a reference, as reported by Amit Khandekar. Also, make sure it works to return a string value for a composite type, so long as the string meets the type's input format. We already allowed the equivalent behavior for arrays, so it seems inconsistent to not allow it for composites. In addition, ensure we throw errors for attempts to return arrays or hashes when the function's declared result type is not an array or composite type, respectively. Pre-9.1 versions rather uselessly returned strings like ARRAY(0x221a9a0) or HASH(0x221aa90), while 9.1.0 threw an error for the hash case and returned a garbage value for the array case. Also, clean up assorted grotty coding in Perl array conversion, including use of a session-lifespan memory context to accumulate the array value (resulting in session-lifespan memory leak on error), failure to apply the declared typmod if any, and failure to detect some cases of non-rectangular multi-dimensional arrays. Alex Hunsaker and Tom Lane
2011-10-14 00:02:43 +02:00
/* handle references */
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
SV *sav = get_perl_array_ref(sv);
if (sav)
{
Fix up Perl-to-Postgres datatype conversions in pl/perl. This patch restores the pre-9.1 behavior that pl/perl functions returning VOID ignore the result value of their last Perl statement. 9.1.0 unintentionally threw an error if the last statement returned a reference, as reported by Amit Khandekar. Also, make sure it works to return a string value for a composite type, so long as the string meets the type's input format. We already allowed the equivalent behavior for arrays, so it seems inconsistent to not allow it for composites. In addition, ensure we throw errors for attempts to return arrays or hashes when the function's declared result type is not an array or composite type, respectively. Pre-9.1 versions rather uselessly returned strings like ARRAY(0x221a9a0) or HASH(0x221aa90), while 9.1.0 threw an error for the hash case and returned a garbage value for the array case. Also, clean up assorted grotty coding in Perl array conversion, including use of a session-lifespan memory context to accumulate the array value (resulting in session-lifespan memory leak on error), failure to apply the declared typmod if any, and failure to detect some cases of non-rectangular multi-dimensional arrays. Alex Hunsaker and Tom Lane
2011-10-14 00:02:43 +02:00
/* handle an arrayref */
return plperl_array_to_datum(sav, typid, typmod);
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
}
else if (SvTYPE(SvRV(sv)) == SVt_PVHV)
{
Fix up Perl-to-Postgres datatype conversions in pl/perl. This patch restores the pre-9.1 behavior that pl/perl functions returning VOID ignore the result value of their last Perl statement. 9.1.0 unintentionally threw an error if the last statement returned a reference, as reported by Amit Khandekar. Also, make sure it works to return a string value for a composite type, so long as the string meets the type's input format. We already allowed the equivalent behavior for arrays, so it seems inconsistent to not allow it for composites. In addition, ensure we throw errors for attempts to return arrays or hashes when the function's declared result type is not an array or composite type, respectively. Pre-9.1 versions rather uselessly returned strings like ARRAY(0x221a9a0) or HASH(0x221aa90), while 9.1.0 threw an error for the hash case and returned a garbage value for the array case. Also, clean up assorted grotty coding in Perl array conversion, including use of a session-lifespan memory context to accumulate the array value (resulting in session-lifespan memory leak on error), failure to apply the declared typmod if any, and failure to detect some cases of non-rectangular multi-dimensional arrays. Alex Hunsaker and Tom Lane
2011-10-14 00:02:43 +02:00
/* handle a hashref */
Datum ret;
TupleDesc td;
Support domains over composite types in PL/Perl. In passing, don't insist on rsi->expectedDesc being set unless we actually need it; this allows succeeding in a couple of cases where PL/Perl functions returning setof composite would have failed before, and makes the error message more apropos in other cases. Discussion: https://postgr.es/m/4206.1499798337@sss.pgh.pa.us
2017-10-28 20:02:21 +02:00
bool isdomain;
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
Fix up Perl-to-Postgres datatype conversions in pl/perl. This patch restores the pre-9.1 behavior that pl/perl functions returning VOID ignore the result value of their last Perl statement. 9.1.0 unintentionally threw an error if the last statement returned a reference, as reported by Amit Khandekar. Also, make sure it works to return a string value for a composite type, so long as the string meets the type's input format. We already allowed the equivalent behavior for arrays, so it seems inconsistent to not allow it for composites. In addition, ensure we throw errors for attempts to return arrays or hashes when the function's declared result type is not an array or composite type, respectively. Pre-9.1 versions rather uselessly returned strings like ARRAY(0x221a9a0) or HASH(0x221aa90), while 9.1.0 threw an error for the hash case and returned a garbage value for the array case. Also, clean up assorted grotty coding in Perl array conversion, including use of a session-lifespan memory context to accumulate the array value (resulting in session-lifespan memory leak on error), failure to apply the declared typmod if any, and failure to detect some cases of non-rectangular multi-dimensional arrays. Alex Hunsaker and Tom Lane
2011-10-14 00:02:43 +02:00
if (!type_is_rowtype(typid))
ereport(ERROR,
(errcode(ERRCODE_DATATYPE_MISMATCH),
errmsg("cannot convert Perl hash to non-composite type %s",
format_type_be(typid))));
Support domains over composite types in PL/Perl. In passing, don't insist on rsi->expectedDesc being set unless we actually need it; this allows succeeding in a couple of cases where PL/Perl functions returning setof composite would have failed before, and makes the error message more apropos in other cases. Discussion: https://postgr.es/m/4206.1499798337@sss.pgh.pa.us
2017-10-28 20:02:21 +02:00
td = lookup_rowtype_tupdesc_domain(typid, typmod, true);
if (td != NULL)
Fix up Perl-to-Postgres datatype conversions in pl/perl. This patch restores the pre-9.1 behavior that pl/perl functions returning VOID ignore the result value of their last Perl statement. 9.1.0 unintentionally threw an error if the last statement returned a reference, as reported by Amit Khandekar. Also, make sure it works to return a string value for a composite type, so long as the string meets the type's input format. We already allowed the equivalent behavior for arrays, so it seems inconsistent to not allow it for composites. In addition, ensure we throw errors for attempts to return arrays or hashes when the function's declared result type is not an array or composite type, respectively. Pre-9.1 versions rather uselessly returned strings like ARRAY(0x221a9a0) or HASH(0x221aa90), while 9.1.0 threw an error for the hash case and returned a garbage value for the array case. Also, clean up assorted grotty coding in Perl array conversion, including use of a session-lifespan memory context to accumulate the array value (resulting in session-lifespan memory leak on error), failure to apply the declared typmod if any, and failure to detect some cases of non-rectangular multi-dimensional arrays. Alex Hunsaker and Tom Lane
2011-10-14 00:02:43 +02:00
{
Support domains over composite types in PL/Perl. In passing, don't insist on rsi->expectedDesc being set unless we actually need it; this allows succeeding in a couple of cases where PL/Perl functions returning setof composite would have failed before, and makes the error message more apropos in other cases. Discussion: https://postgr.es/m/4206.1499798337@sss.pgh.pa.us
2017-10-28 20:02:21 +02:00
/* Did we look through a domain? */
isdomain = (typid != td->tdtypeid);
}
else
{
/* Must be RECORD, try to resolve based on call info */
TypeFuncClass funcclass;
if (fcinfo)
funcclass = get_call_result_type(fcinfo, &typid, &td);
else
funcclass = TYPEFUNC_OTHER;
if (funcclass != TYPEFUNC_COMPOSITE &&
funcclass != TYPEFUNC_COMPOSITE_DOMAIN)
Fix up Perl-to-Postgres datatype conversions in pl/perl. This patch restores the pre-9.1 behavior that pl/perl functions returning VOID ignore the result value of their last Perl statement. 9.1.0 unintentionally threw an error if the last statement returned a reference, as reported by Amit Khandekar. Also, make sure it works to return a string value for a composite type, so long as the string meets the type's input format. We already allowed the equivalent behavior for arrays, so it seems inconsistent to not allow it for composites. In addition, ensure we throw errors for attempts to return arrays or hashes when the function's declared result type is not an array or composite type, respectively. Pre-9.1 versions rather uselessly returned strings like ARRAY(0x221a9a0) or HASH(0x221aa90), while 9.1.0 threw an error for the hash case and returned a garbage value for the array case. Also, clean up assorted grotty coding in Perl array conversion, including use of a session-lifespan memory context to accumulate the array value (resulting in session-lifespan memory leak on error), failure to apply the declared typmod if any, and failure to detect some cases of non-rectangular multi-dimensional arrays. Alex Hunsaker and Tom Lane
2011-10-14 00:02:43 +02:00
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("function returning record called in context "
"that cannot accept type record")));
Support domains over composite types in PL/Perl. In passing, don't insist on rsi->expectedDesc being set unless we actually need it; this allows succeeding in a couple of cases where PL/Perl functions returning setof composite would have failed before, and makes the error message more apropos in other cases. Discussion: https://postgr.es/m/4206.1499798337@sss.pgh.pa.us
2017-10-28 20:02:21 +02:00
Assert(td);
isdomain = (funcclass == TYPEFUNC_COMPOSITE_DOMAIN);
Fix up Perl-to-Postgres datatype conversions in pl/perl. This patch restores the pre-9.1 behavior that pl/perl functions returning VOID ignore the result value of their last Perl statement. 9.1.0 unintentionally threw an error if the last statement returned a reference, as reported by Amit Khandekar. Also, make sure it works to return a string value for a composite type, so long as the string meets the type's input format. We already allowed the equivalent behavior for arrays, so it seems inconsistent to not allow it for composites. In addition, ensure we throw errors for attempts to return arrays or hashes when the function's declared result type is not an array or composite type, respectively. Pre-9.1 versions rather uselessly returned strings like ARRAY(0x221a9a0) or HASH(0x221aa90), while 9.1.0 threw an error for the hash case and returned a garbage value for the array case. Also, clean up assorted grotty coding in Perl array conversion, including use of a session-lifespan memory context to accumulate the array value (resulting in session-lifespan memory leak on error), failure to apply the declared typmod if any, and failure to detect some cases of non-rectangular multi-dimensional arrays. Alex Hunsaker and Tom Lane
2011-10-14 00:02:43 +02:00
}
ret = plperl_hash_to_datum(sv, td);
Support domains over composite types in PL/Perl. In passing, don't insist on rsi->expectedDesc being set unless we actually need it; this allows succeeding in a couple of cases where PL/Perl functions returning setof composite would have failed before, and makes the error message more apropos in other cases. Discussion: https://postgr.es/m/4206.1499798337@sss.pgh.pa.us
2017-10-28 20:02:21 +02:00
if (isdomain)
domain_check(ret, false, typid, NULL, NULL);
Fix up Perl-to-Postgres datatype conversions in pl/perl. This patch restores the pre-9.1 behavior that pl/perl functions returning VOID ignore the result value of their last Perl statement. 9.1.0 unintentionally threw an error if the last statement returned a reference, as reported by Amit Khandekar. Also, make sure it works to return a string value for a composite type, so long as the string meets the type's input format. We already allowed the equivalent behavior for arrays, so it seems inconsistent to not allow it for composites. In addition, ensure we throw errors for attempts to return arrays or hashes when the function's declared result type is not an array or composite type, respectively. Pre-9.1 versions rather uselessly returned strings like ARRAY(0x221a9a0) or HASH(0x221aa90), while 9.1.0 threw an error for the hash case and returned a garbage value for the array case. Also, clean up assorted grotty coding in Perl array conversion, including use of a session-lifespan memory context to accumulate the array value (resulting in session-lifespan memory leak on error), failure to apply the declared typmod if any, and failure to detect some cases of non-rectangular multi-dimensional arrays. Alex Hunsaker and Tom Lane
2011-10-14 00:02:43 +02:00
/* Release on the result of get_call_result_type is harmless */
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
ReleaseTupleDesc(td);
Fix up Perl-to-Postgres datatype conversions in pl/perl. This patch restores the pre-9.1 behavior that pl/perl functions returning VOID ignore the result value of their last Perl statement. 9.1.0 unintentionally threw an error if the last statement returned a reference, as reported by Amit Khandekar. Also, make sure it works to return a string value for a composite type, so long as the string meets the type's input format. We already allowed the equivalent behavior for arrays, so it seems inconsistent to not allow it for composites. In addition, ensure we throw errors for attempts to return arrays or hashes when the function's declared result type is not an array or composite type, respectively. Pre-9.1 versions rather uselessly returned strings like ARRAY(0x221a9a0) or HASH(0x221aa90), while 9.1.0 threw an error for the hash case and returned a garbage value for the array case. Also, clean up assorted grotty coding in Perl array conversion, including use of a session-lifespan memory context to accumulate the array value (resulting in session-lifespan memory leak on error), failure to apply the declared typmod if any, and failure to detect some cases of non-rectangular multi-dimensional arrays. Alex Hunsaker and Tom Lane
2011-10-14 00:02:43 +02:00
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
return ret;
}
Allow plperl_sv_to_datum to look through scalar refs. There seems little reason for the policy of throwing error if we find a ref to something other than a hash or array. Recursively look through the ref, instead. This makes the behavior in non-transform cases comparable to what was already instantiated for jsonb_plperl. Note that because we invoke any available transform function before considering the ref case, it's up to each transform function whether it wants to play along with this behavior or do something different. Because the previous behavior was just to throw a useless error, this seems unlikely to create any compatibility issues. Still, given the lack of field complaints so far, seems best not to back-patch. Discussion: https://postgr.es/m/28336.1528393969@sss.pgh.pa.us
2018-06-18 21:31:57 +02:00
/*
* If it's a reference to something else, such as a scalar, just
* recursively look through the reference.
*/
return plperl_sv_to_datum(SvRV(sv), typid, typmod,
fcinfo, finfo, typioparam,
isnull);
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
}
else
{
Fix up Perl-to-Postgres datatype conversions in pl/perl. This patch restores the pre-9.1 behavior that pl/perl functions returning VOID ignore the result value of their last Perl statement. 9.1.0 unintentionally threw an error if the last statement returned a reference, as reported by Amit Khandekar. Also, make sure it works to return a string value for a composite type, so long as the string meets the type's input format. We already allowed the equivalent behavior for arrays, so it seems inconsistent to not allow it for composites. In addition, ensure we throw errors for attempts to return arrays or hashes when the function's declared result type is not an array or composite type, respectively. Pre-9.1 versions rather uselessly returned strings like ARRAY(0x221a9a0) or HASH(0x221aa90), while 9.1.0 threw an error for the hash case and returned a garbage value for the array case. Also, clean up assorted grotty coding in Perl array conversion, including use of a session-lifespan memory context to accumulate the array value (resulting in session-lifespan memory leak on error), failure to apply the declared typmod if any, and failure to detect some cases of non-rectangular multi-dimensional arrays. Alex Hunsaker and Tom Lane
2011-10-14 00:02:43 +02:00
/* handle a string/number */
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
Datum ret;
char *str = sv2cstr(sv);
Fix up Perl-to-Postgres datatype conversions in pl/perl. This patch restores the pre-9.1 behavior that pl/perl functions returning VOID ignore the result value of their last Perl statement. 9.1.0 unintentionally threw an error if the last statement returned a reference, as reported by Amit Khandekar. Also, make sure it works to return a string value for a composite type, so long as the string meets the type's input format. We already allowed the equivalent behavior for arrays, so it seems inconsistent to not allow it for composites. In addition, ensure we throw errors for attempts to return arrays or hashes when the function's declared result type is not an array or composite type, respectively. Pre-9.1 versions rather uselessly returned strings like ARRAY(0x221a9a0) or HASH(0x221aa90), while 9.1.0 threw an error for the hash case and returned a garbage value for the array case. Also, clean up assorted grotty coding in Perl array conversion, including use of a session-lifespan memory context to accumulate the array value (resulting in session-lifespan memory leak on error), failure to apply the declared typmod if any, and failure to detect some cases of non-rectangular multi-dimensional arrays. Alex Hunsaker and Tom Lane
2011-10-14 00:02:43 +02:00
/* did not pass in any typeinfo? look it up */
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
if (!finfo)
{
Fix up Perl-to-Postgres datatype conversions in pl/perl. This patch restores the pre-9.1 behavior that pl/perl functions returning VOID ignore the result value of their last Perl statement. 9.1.0 unintentionally threw an error if the last statement returned a reference, as reported by Amit Khandekar. Also, make sure it works to return a string value for a composite type, so long as the string meets the type's input format. We already allowed the equivalent behavior for arrays, so it seems inconsistent to not allow it for composites. In addition, ensure we throw errors for attempts to return arrays or hashes when the function's declared result type is not an array or composite type, respectively. Pre-9.1 versions rather uselessly returned strings like ARRAY(0x221a9a0) or HASH(0x221aa90), while 9.1.0 threw an error for the hash case and returned a garbage value for the array case. Also, clean up assorted grotty coding in Perl array conversion, including use of a session-lifespan memory context to accumulate the array value (resulting in session-lifespan memory leak on error), failure to apply the declared typmod if any, and failure to detect some cases of non-rectangular multi-dimensional arrays. Alex Hunsaker and Tom Lane
2011-10-14 00:02:43 +02:00
_sv_to_datum_finfo(typid, &tmp, &typioparam);
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
finfo = &tmp;
}
ret = InputFunctionCall(finfo, str, typioparam, typmod);
pfree(str);
return ret;
}
}
/* Convert the perl SV to a string returned by the type output function */
char *
plperl_sv_to_literal(SV *sv, char *fqtypename)
{
Disallow execution of SPI functions during plperl function compilation. Perl can be convinced to execute user-defined code during compilation of a plperl function (or at least a plperlu function). That's not such a big problem as long as the activity is confined within the Perl interpreter, and it's not clear we could do anything about that anyway. However, if such code tries to use plperl's SPI functions, we have a bigger problem. In the first place, those functions are likely to crash because current_call_data->prodesc isn't set up yet. In the second place, because it isn't set up, we lack critical info such as whether the function is supposed to be read-only. And in the third place, this path allows code execution during function validation, which is strongly discouraged because of the potential for security exploits. Hence, reject execution of the SPI functions until compilation is finished. While here, add check_spi_usage_allowed() calls to various functions that hadn't gotten the memo about checking that. I think that perhaps plperl_sv_to_literal may have been intentionally omitted on the grounds that it was safe at the time; but if so, the addition of transforms functionality changed that. The others are more recently added and seem to be flat-out oversights. Per report from Mark Murawski. Back-patch to all supported branches. Discussion: https://postgr.es/m/9acdf918-7fff-4f40-f750-2ffa84f083d2@intellasoft.net
2022-02-25 23:40:21 +01:00
Oid typid;
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
Oid typoutput;
Datum datum;
bool typisvarlena,
isnull;
Disallow execution of SPI functions during plperl function compilation. Perl can be convinced to execute user-defined code during compilation of a plperl function (or at least a plperlu function). That's not such a big problem as long as the activity is confined within the Perl interpreter, and it's not clear we could do anything about that anyway. However, if such code tries to use plperl's SPI functions, we have a bigger problem. In the first place, those functions are likely to crash because current_call_data->prodesc isn't set up yet. In the second place, because it isn't set up, we lack critical info such as whether the function is supposed to be read-only. And in the third place, this path allows code execution during function validation, which is strongly discouraged because of the potential for security exploits. Hence, reject execution of the SPI functions until compilation is finished. While here, add check_spi_usage_allowed() calls to various functions that hadn't gotten the memo about checking that. I think that perhaps plperl_sv_to_literal may have been intentionally omitted on the grounds that it was safe at the time; but if so, the addition of transforms functionality changed that. The others are more recently added and seem to be flat-out oversights. Per report from Mark Murawski. Back-patch to all supported branches. Discussion: https://postgr.es/m/9acdf918-7fff-4f40-f750-2ffa84f083d2@intellasoft.net
2022-02-25 23:40:21 +01:00
check_spi_usage_allowed();
typid = DirectFunctionCall1(regtypein, CStringGetDatum(fqtypename));
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
if (!OidIsValid(typid))
Fix a number of places that produced XX000 errors in the regression tests. It's against project policy to use elog() for user-facing errors, or to omit an errcode() selection for errors that aren't supposed to be "can't happen" cases. Fix all the violations of this policy that result in ERRCODE_INTERNAL_ERROR log entries during the standard regression tests, as errors that can reliably be triggered from SQL surely should be considered user-facing. I also looked through all the files touched by this commit and fixed other nearby problems of the same ilk. I do not claim to have fixed all violations of the policy, just the ones in these files. In a few places I also changed existing ERRCODE choices that didn't seem particularly appropriate; mainly replacing ERRCODE_SYNTAX_ERROR by something more specific. Back-patch to 9.5, but no further; changing ERRCODE assignments in stable branches doesn't seem like a good idea.
2015-08-03 05:49:19 +02:00
ereport(ERROR,
(errcode(ERRCODE_UNDEFINED_OBJECT),
errmsg("lookup failed for type %s", fqtypename)));
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
Fix up Perl-to-Postgres datatype conversions in pl/perl. This patch restores the pre-9.1 behavior that pl/perl functions returning VOID ignore the result value of their last Perl statement. 9.1.0 unintentionally threw an error if the last statement returned a reference, as reported by Amit Khandekar. Also, make sure it works to return a string value for a composite type, so long as the string meets the type's input format. We already allowed the equivalent behavior for arrays, so it seems inconsistent to not allow it for composites. In addition, ensure we throw errors for attempts to return arrays or hashes when the function's declared result type is not an array or composite type, respectively. Pre-9.1 versions rather uselessly returned strings like ARRAY(0x221a9a0) or HASH(0x221aa90), while 9.1.0 threw an error for the hash case and returned a garbage value for the array case. Also, clean up assorted grotty coding in Perl array conversion, including use of a session-lifespan memory context to accumulate the array value (resulting in session-lifespan memory leak on error), failure to apply the declared typmod if any, and failure to detect some cases of non-rectangular multi-dimensional arrays. Alex Hunsaker and Tom Lane
2011-10-14 00:02:43 +02:00
datum = plperl_sv_to_datum(sv,
typid, -1,
NULL, NULL, InvalidOid,
&isnull);
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
if (isnull)
return NULL;
getTypeOutputInfo(typid,
&typoutput, &typisvarlena);
return OidOutputFunctionCall(typoutput, datum);
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
}
Following up a previous thought I had, yesterday I realised how to return arays nicely without having to make the plperl programmer aware of anything. The attached patch allows plperl to return an arrayref where the function returns an array type. It silently calls a perl function to stringify the array before passing it to the pg array parser. Non-array returns are handled as before (i.e. passed through this process) so it is backwards compatible. I will presently submit regression tests and docs. example: andrew=# create or replace function blah() returns text[][] language plperl as $$ return [['a"b','c,d'],['e\\f','g']]; $$; CREATE FUNCTION andrew=# select blah(); blah ----------------------------- {{"a\"b","c,d"},{"e\\f",g}} This would complete half of the TODO item: . Pass arrays natively instead of as text between plperl and postgres (The other half is translating pg array arguments to perl arrays - that will have to wait for 8.1). Some of this patch is adapted from a previously submitted patch from Sergej Sergeev. Both he and Abhijit Menon-Sen have looked it over briefly and tentatively said it looks ok. Andrew Dunstan
2005-07-10 17:32:47 +02:00
/*
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
* Convert PostgreSQL array datum to a perl array reference.
*
* typid is arg's OID, which must be an array type.
Following up a previous thought I had, yesterday I realised how to return arays nicely without having to make the plperl programmer aware of anything. The attached patch allows plperl to return an arrayref where the function returns an array type. It silently calls a perl function to stringify the array before passing it to the pg array parser. Non-array returns are handled as before (i.e. passed through this process) so it is backwards compatible. I will presently submit regression tests and docs. example: andrew=# create or replace function blah() returns text[][] language plperl as $$ return [['a"b','c,d'],['e\\f','g']]; $$; CREATE FUNCTION andrew=# select blah(); blah ----------------------------- {{"a\"b","c,d"},{"e\\f",g}} This would complete half of the TODO item: . Pass arrays natively instead of as text between plperl and postgres (The other half is translating pg array arguments to perl arrays - that will have to wait for 8.1). Some of this patch is adapted from a previously submitted patch from Sergej Sergeev. Both he and Abhijit Menon-Sen have looked it over briefly and tentatively said it looks ok. Andrew Dunstan
2005-07-10 17:32:47 +02:00
*/
static SV *
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
plperl_ref_from_pg_array(Datum arg, Oid typid)
Following up a previous thought I had, yesterday I realised how to return arays nicely without having to make the plperl programmer aware of anything. The attached patch allows plperl to return an arrayref where the function returns an array type. It silently calls a perl function to stringify the array before passing it to the pg array parser. Non-array returns are handled as before (i.e. passed through this process) so it is backwards compatible. I will presently submit regression tests and docs. example: andrew=# create or replace function blah() returns text[][] language plperl as $$ return [['a"b','c,d'],['e\\f','g']]; $$; CREATE FUNCTION andrew=# select blah(); blah ----------------------------- {{"a\"b","c,d"},{"e\\f",g}} This would complete half of the TODO item: . Pass arrays natively instead of as text between plperl and postgres (The other half is translating pg array arguments to perl arrays - that will have to wait for 8.1). Some of this patch is adapted from a previously submitted patch from Sergej Sergeev. Both he and Abhijit Menon-Sen have looked it over briefly and tentatively said it looks ok. Andrew Dunstan
2005-07-10 17:32:47 +02:00
{
PL/Perl portability fix: avoid including XSUB.h in plperl.c. In Perl builds that define PERL_IMPLICIT_SYS, XSUB.h defines macros that replace a whole lot of basic libc functions with Perl functions. We can't tolerate that in plperl.c; it breaks at least PG_TRY and probably other stuff. The core idea of this patch is to include XSUB.h only in the .xs files where it's really needed, and to move any code broken by PERL_IMPLICIT_SYS out of the .xs files and into plperl.c. The reason this hasn't been a problem before is that our build techniques did not result in PERL_IMPLICIT_SYS appearing as a #define in PL/Perl, even on some platforms where Perl thinks it is defined. That's about to change in order to fix a nasty portability issue, so we need this work to make the code safe for that. Rather unaccountably, the Perl people chose XSUB.h as the place to provide the versions of the aTHX/aTHX_ macros that are needed by code that's not explicitly aware of the MULTIPLICITY API conventions. Hence, just removing XSUB.h from plperl.c fails miserably. But we can work around that by defining PERL_NO_GET_CONTEXT (which would make the relevant stanza of XSUB.h a no-op anyway). As explained in perlguts.pod, that means we need to add a "dTHX" macro call in every C function that calls a Perl API function. In most of them we just add this at the top; but since the macro fetches the current Perl interpreter pointer, more care is needed in functions that switch the active interpreter. Lack of the macro is easily recognized since it results in bleats about "my_perl" not being defined. (A nice side benefit of this is that it significantly reduces the number of fetches of the current interpreter pointer. On my machine, plperl.so gets more than 10% smaller, and there's probably some performance win too. We could reduce the number of fetches still more by decorating the code with pTHX_/aTHX_ macros to pass the interpreter pointer around, as explained by perlguts.pod; but that's a task for another day.) Formatting note: pgindent seems happy to treat "dTHX;" as a declaration so long as it's the first thing after the left brace, as we'd already observed with respect to the similar macro "dSP;". If you try to put it later in a set of declarations, pgindent puts ugly extra space around it. Having removed XSUB.h from plperl.c, we need only move the support functions for spi_return_next and util_elog (both of which use PG_TRY) out of the .xs files and into plperl.c. This seems sufficient to avoid the known problems caused by PERL_IMPLICIT_SYS, although we could move more code if additional issues emerge. This will need to be back-patched, but first let's see what the buildfarm makes of it. Patch by me, with some help from Ashutosh Sharma Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
2017-07-28 18:25:43 +02:00
dTHX;
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
ArrayType *ar = DatumGetArrayTypeP(arg);
Oid elementtype = ARR_ELEMTYPE(ar);
int16 typlen;
bool typbyval;
char typalign,
typdelim;
Oid typioparam;
Oid typoutputfunc;
Add transforms feature This provides a mechanism for specifying conversions between SQL data types and procedural languages. As examples, there are transforms for hstore and ltree for PL/Perl and PL/Python. reviews by Pavel Stěhule and Andres Freund
2015-04-26 16:33:14 +02:00
Oid transform_funcid;
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
int i,
nitems,
*dims;
plperl_array_info *info;
SV *av;
HV *hv;
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
Improve memory management for PL/Perl functions. Unlike PL/Tcl, PL/Perl at least made an attempt to clean up after itself when a function gets redefined. But it was still using TopMemoryContext for the fn_mcxt of argument/result I/O functions, resulting in the potential for memory leaks depending on what those functions did, and the retail alloc/free logic was pretty bulky as well. Fix things to use a per-function memory context like the other PLs now do. Tweak a couple of places where things were being done in a not-very-safe order (on the principle that a memory leak is better than leaving global state inconsistent after an error). Also make some minor cosmetic adjustments, mostly in field names, to make the code look similar to the way PL/Tcl does now wherever it's essentially the same logic. Michael Paquier and Tom Lane Discussion: <CAB7nPqSOyAsHC6jL24J1B+oK3p=yyNoFU0Vs_B6fd2kdd5g5WQ@mail.gmail.com>
2016-09-01 01:54:58 +02:00
/*
* Currently we make no effort to cache any of the stuff we look up here,
* which is bad.
*/
Add transforms feature This provides a mechanism for specifying conversions between SQL data types and procedural languages. As examples, there are transforms for hstore and ltree for PL/Perl and PL/Python. reviews by Pavel Stěhule and Andres Freund
2015-04-26 16:33:14 +02:00
info = palloc0(sizeof(plperl_array_info));
Following up a previous thought I had, yesterday I realised how to return arays nicely without having to make the plperl programmer aware of anything. The attached patch allows plperl to return an arrayref where the function returns an array type. It silently calls a perl function to stringify the array before passing it to the pg array parser. Non-array returns are handled as before (i.e. passed through this process) so it is backwards compatible. I will presently submit regression tests and docs. example: andrew=# create or replace function blah() returns text[][] language plperl as $$ return [['a"b','c,d'],['e\\f','g']]; $$; CREATE FUNCTION andrew=# select blah(); blah ----------------------------- {{"a\"b","c,d"},{"e\\f",g}} This would complete half of the TODO item: . Pass arrays natively instead of as text between plperl and postgres (The other half is translating pg array arguments to perl arrays - that will have to wait for 8.1). Some of this patch is adapted from a previously submitted patch from Sergej Sergeev. Both he and Abhijit Menon-Sen have looked it over briefly and tentatively said it looks ok. Andrew Dunstan
2005-07-10 17:32:47 +02:00
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
/* get element type information, including output conversion function */
get_type_io_data(elementtype, IOFunc_output,
&typlen, &typbyval, &typalign,
&typdelim, &typioparam, &typoutputfunc);
Following up a previous thought I had, yesterday I realised how to return arays nicely without having to make the plperl programmer aware of anything. The attached patch allows plperl to return an arrayref where the function returns an array type. It silently calls a perl function to stringify the array before passing it to the pg array parser. Non-array returns are handled as before (i.e. passed through this process) so it is backwards compatible. I will presently submit regression tests and docs. example: andrew=# create or replace function blah() returns text[][] language plperl as $$ return [['a"b','c,d'],['e\\f','g']]; $$; CREATE FUNCTION andrew=# select blah(); blah ----------------------------- {{"a\"b","c,d"},{"e\\f",g}} This would complete half of the TODO item: . Pass arrays natively instead of as text between plperl and postgres (The other half is translating pg array arguments to perl arrays - that will have to wait for 8.1). Some of this patch is adapted from a previously submitted patch from Sergej Sergeev. Both he and Abhijit Menon-Sen have looked it over briefly and tentatively said it looks ok. Andrew Dunstan
2005-07-10 17:32:47 +02:00
Improve memory management for PL/Perl functions. Unlike PL/Tcl, PL/Perl at least made an attempt to clean up after itself when a function gets redefined. But it was still using TopMemoryContext for the fn_mcxt of argument/result I/O functions, resulting in the potential for memory leaks depending on what those functions did, and the retail alloc/free logic was pretty bulky as well. Fix things to use a per-function memory context like the other PLs now do. Tweak a couple of places where things were being done in a not-very-safe order (on the principle that a memory leak is better than leaving global state inconsistent after an error). Also make some minor cosmetic adjustments, mostly in field names, to make the code look similar to the way PL/Tcl does now wherever it's essentially the same logic. Michael Paquier and Tom Lane Discussion: <CAB7nPqSOyAsHC6jL24J1B+oK3p=yyNoFU0Vs_B6fd2kdd5g5WQ@mail.gmail.com>
2016-09-01 01:54:58 +02:00
/* Check for a transform function */
transform_funcid = get_transform_fromsql(elementtype,
current_call_data->prodesc->lang_oid,
current_call_data->prodesc->trftypes);
/* Look up transform or output function as appropriate */
if (OidIsValid(transform_funcid))
fmgr_info(transform_funcid, &info->transform_proc);
Add transforms feature This provides a mechanism for specifying conversions between SQL data types and procedural languages. As examples, there are transforms for hstore and ltree for PL/Perl and PL/Python. reviews by Pavel Stěhule and Andres Freund
2015-04-26 16:33:14 +02:00
else
Improve memory management for PL/Perl functions. Unlike PL/Tcl, PL/Perl at least made an attempt to clean up after itself when a function gets redefined. But it was still using TopMemoryContext for the fn_mcxt of argument/result I/O functions, resulting in the potential for memory leaks depending on what those functions did, and the retail alloc/free logic was pretty bulky as well. Fix things to use a per-function memory context like the other PLs now do. Tweak a couple of places where things were being done in a not-very-safe order (on the principle that a memory leak is better than leaving global state inconsistent after an error). Also make some minor cosmetic adjustments, mostly in field names, to make the code look similar to the way PL/Tcl does now wherever it's essentially the same logic. Michael Paquier and Tom Lane Discussion: <CAB7nPqSOyAsHC6jL24J1B+oK3p=yyNoFU0Vs_B6fd2kdd5g5WQ@mail.gmail.com>
2016-09-01 01:54:58 +02:00
fmgr_info(typoutputfunc, &info->proc);
Following up a previous thought I had, yesterday I realised how to return arays nicely without having to make the plperl programmer aware of anything. The attached patch allows plperl to return an arrayref where the function returns an array type. It silently calls a perl function to stringify the array before passing it to the pg array parser. Non-array returns are handled as before (i.e. passed through this process) so it is backwards compatible. I will presently submit regression tests and docs. example: andrew=# create or replace function blah() returns text[][] language plperl as $$ return [['a"b','c,d'],['e\\f','g']]; $$; CREATE FUNCTION andrew=# select blah(); blah ----------------------------- {{"a\"b","c,d"},{"e\\f",g}} This would complete half of the TODO item: . Pass arrays natively instead of as text between plperl and postgres (The other half is translating pg array arguments to perl arrays - that will have to wait for 8.1). Some of this patch is adapted from a previously submitted patch from Sergej Sergeev. Both he and Abhijit Menon-Sen have looked it over briefly and tentatively said it looks ok. Andrew Dunstan
2005-07-10 17:32:47 +02:00
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
info->elem_is_rowtype = type_is_rowtype(elementtype);
Following up a previous thought I had, yesterday I realised how to return arays nicely without having to make the plperl programmer aware of anything. The attached patch allows plperl to return an arrayref where the function returns an array type. It silently calls a perl function to stringify the array before passing it to the pg array parser. Non-array returns are handled as before (i.e. passed through this process) so it is backwards compatible. I will presently submit regression tests and docs. example: andrew=# create or replace function blah() returns text[][] language plperl as $$ return [['a"b','c,d'],['e\\f','g']]; $$; CREATE FUNCTION andrew=# select blah(); blah ----------------------------- {{"a\"b","c,d"},{"e\\f",g}} This would complete half of the TODO item: . Pass arrays natively instead of as text between plperl and postgres (The other half is translating pg array arguments to perl arrays - that will have to wait for 8.1). Some of this patch is adapted from a previously submitted patch from Sergej Sergeev. Both he and Abhijit Menon-Sen have looked it over briefly and tentatively said it looks ok. Andrew Dunstan
2005-07-10 17:32:47 +02:00
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
/* Get the number and bounds of array dimensions */
info->ndims = ARR_NDIM(ar);
dims = ARR_DIMS(ar);
Following up a previous thought I had, yesterday I realised how to return arays nicely without having to make the plperl programmer aware of anything. The attached patch allows plperl to return an arrayref where the function returns an array type. It silently calls a perl function to stringify the array before passing it to the pg array parser. Non-array returns are handled as before (i.e. passed through this process) so it is backwards compatible. I will presently submit regression tests and docs. example: andrew=# create or replace function blah() returns text[][] language plperl as $$ return [['a"b','c,d'],['e\\f','g']]; $$; CREATE FUNCTION andrew=# select blah(); blah ----------------------------- {{"a\"b","c,d"},{"e\\f",g}} This would complete half of the TODO item: . Pass arrays natively instead of as text between plperl and postgres (The other half is translating pg array arguments to perl arrays - that will have to wait for 8.1). Some of this patch is adapted from a previously submitted patch from Sergej Sergeev. Both he and Abhijit Menon-Sen have looked it over briefly and tentatively said it looks ok. Andrew Dunstan
2005-07-10 17:32:47 +02:00
plperl: Correctly handle empty arrays in plperl_ref_from_pg_array. plperl_ref_from_pg_array() didn't consider the case that postgrs arrays can have 0 dimensions (when they're empty) and accessed the first dimension without a check. Fix that by special casing the empty array case. Author: Alex Hunsaker Reported-By: Andres Freund / valgrind / buildfarm animal skink Discussion: 20160308063240.usnzg6bsbjrne667@alap3.anarazel.de Backpatch: 9.1-
2016-03-08 22:33:24 +01:00
/* No dimensions? Return an empty array */
if (info->ndims == 0)
{
av = newRV_noinc((SV *) newAV());
}
else
{
deconstruct_array(ar, elementtype, typlen, typbyval,
typalign, &info->elements, &info->nulls,
&nitems);
Following up a previous thought I had, yesterday I realised how to return arays nicely without having to make the plperl programmer aware of anything. The attached patch allows plperl to return an arrayref where the function returns an array type. It silently calls a perl function to stringify the array before passing it to the pg array parser. Non-array returns are handled as before (i.e. passed through this process) so it is backwards compatible. I will presently submit regression tests and docs. example: andrew=# create or replace function blah() returns text[][] language plperl as $$ return [['a"b','c,d'],['e\\f','g']]; $$; CREATE FUNCTION andrew=# select blah(); blah ----------------------------- {{"a\"b","c,d"},{"e\\f",g}} This would complete half of the TODO item: . Pass arrays natively instead of as text between plperl and postgres (The other half is translating pg array arguments to perl arrays - that will have to wait for 8.1). Some of this patch is adapted from a previously submitted patch from Sergej Sergeev. Both he and Abhijit Menon-Sen have looked it over briefly and tentatively said it looks ok. Andrew Dunstan
2005-07-10 17:32:47 +02:00
plperl: Correctly handle empty arrays in plperl_ref_from_pg_array. plperl_ref_from_pg_array() didn't consider the case that postgrs arrays can have 0 dimensions (when they're empty) and accessed the first dimension without a check. Fix that by special casing the empty array case. Author: Alex Hunsaker Reported-By: Andres Freund / valgrind / buildfarm animal skink Discussion: 20160308063240.usnzg6bsbjrne667@alap3.anarazel.de Backpatch: 9.1-
2016-03-08 22:33:24 +01:00
/* Get total number of elements in each dimension */
info->nelems = palloc(sizeof(int) * info->ndims);
info->nelems[0] = nitems;
for (i = 1; i < info->ndims; i++)
info->nelems[i] = info->nelems[i - 1] / dims[i - 1];
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
plperl: Correctly handle empty arrays in plperl_ref_from_pg_array. plperl_ref_from_pg_array() didn't consider the case that postgrs arrays can have 0 dimensions (when they're empty) and accessed the first dimension without a check. Fix that by special casing the empty array case. Author: Alex Hunsaker Reported-By: Andres Freund / valgrind / buildfarm animal skink Discussion: 20160308063240.usnzg6bsbjrne667@alap3.anarazel.de Backpatch: 9.1-
2016-03-08 22:33:24 +01:00
av = split_array(info, 0, nitems, 0);
}
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
hv = newHV();
(void) hv_store(hv, "array", 5, av, 0);
Widen query numbers-of-tuples-processed counters to uint64. This patch widens SPI_processed, EState's es_processed field, PortalData's portalPos field, FuncCallContext's call_cntr and max_calls fields, ExecutorRun's count argument, PortalRunFetch's result, and the max number of rows in a SPITupleTable to uint64, and deals with (I hope) all the ensuing fallout. Some of these values were declared uint32 before, and others "long". I also removed PortalData's posOverflow field, since that logic seems pretty useless given that portalPos is now always 64 bits. The user-visible results are that command tags for SELECT etc will correctly report tuple counts larger than 4G, as will plpgsql's GET GET DIAGNOSTICS ... ROW_COUNT command. Queries processing more tuples than that are still not exactly the norm, but they're becoming more common. Most values associated with FETCH/MOVE distances, such as PortalRun's count argument and the count argument of most SPI functions that have one, remain declared as "long". It's not clear whether it would be worth promoting those to int64; but it would definitely be a large dollop of additional API churn on top of this, and it would only help 32-bit platforms which seem relatively less likely to see any benefit. Andreas Scherbaum, reviewed by Christian Ullrich, additional hacking by me
2016-03-12 22:05:10 +01:00
(void) hv_store(hv, "typeoid", 7, newSVuv(typid), 0);
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
return sv_bless(newRV_noinc((SV *) hv),
gv_stashpv("PostgreSQL::InServer::ARRAY", 0));
Following up a previous thought I had, yesterday I realised how to return arays nicely without having to make the plperl programmer aware of anything. The attached patch allows plperl to return an arrayref where the function returns an array type. It silently calls a perl function to stringify the array before passing it to the pg array parser. Non-array returns are handled as before (i.e. passed through this process) so it is backwards compatible. I will presently submit regression tests and docs. example: andrew=# create or replace function blah() returns text[][] language plperl as $$ return [['a"b','c,d'],['e\\f','g']]; $$; CREATE FUNCTION andrew=# select blah(); blah ----------------------------- {{"a\"b","c,d"},{"e\\f",g}} This would complete half of the TODO item: . Pass arrays natively instead of as text between plperl and postgres (The other half is translating pg array arguments to perl arrays - that will have to wait for 8.1). Some of this patch is adapted from a previously submitted patch from Sergej Sergeev. Both he and Abhijit Menon-Sen have looked it over briefly and tentatively said it looks ok. Andrew Dunstan
2005-07-10 17:32:47 +02:00
}
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
/*
* Recursively form array references from splices of the initial array
*/
static SV *
split_array(plperl_array_info *info, int first, int last, int nest)
{
PL/Perl portability fix: avoid including XSUB.h in plperl.c. In Perl builds that define PERL_IMPLICIT_SYS, XSUB.h defines macros that replace a whole lot of basic libc functions with Perl functions. We can't tolerate that in plperl.c; it breaks at least PG_TRY and probably other stuff. The core idea of this patch is to include XSUB.h only in the .xs files where it's really needed, and to move any code broken by PERL_IMPLICIT_SYS out of the .xs files and into plperl.c. The reason this hasn't been a problem before is that our build techniques did not result in PERL_IMPLICIT_SYS appearing as a #define in PL/Perl, even on some platforms where Perl thinks it is defined. That's about to change in order to fix a nasty portability issue, so we need this work to make the code safe for that. Rather unaccountably, the Perl people chose XSUB.h as the place to provide the versions of the aTHX/aTHX_ macros that are needed by code that's not explicitly aware of the MULTIPLICITY API conventions. Hence, just removing XSUB.h from plperl.c fails miserably. But we can work around that by defining PERL_NO_GET_CONTEXT (which would make the relevant stanza of XSUB.h a no-op anyway). As explained in perlguts.pod, that means we need to add a "dTHX" macro call in every C function that calls a Perl API function. In most of them we just add this at the top; but since the macro fetches the current Perl interpreter pointer, more care is needed in functions that switch the active interpreter. Lack of the macro is easily recognized since it results in bleats about "my_perl" not being defined. (A nice side benefit of this is that it significantly reduces the number of fetches of the current interpreter pointer. On my machine, plperl.so gets more than 10% smaller, and there's probably some performance win too. We could reduce the number of fetches still more by decorating the code with pTHX_/aTHX_ macros to pass the interpreter pointer around, as explained by perlguts.pod; but that's a task for another day.) Formatting note: pgindent seems happy to treat "dTHX;" as a declaration so long as it's the first thing after the left brace, as we'd already observed with respect to the similar macro "dSP;". If you try to put it later in a set of declarations, pgindent puts ugly extra space around it. Having removed XSUB.h from plperl.c, we need only move the support functions for spi_return_next and util_elog (both of which use PG_TRY) out of the .xs files and into plperl.c. This seems sufficient to avoid the known problems caused by PERL_IMPLICIT_SYS, although we could move more code if additional issues emerge. This will need to be back-patched, but first let's see what the buildfarm makes of it. Patch by me, with some help from Ashutosh Sharma Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
2017-07-28 18:25:43 +02:00
dTHX;
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
int i;
AV *result;
I have attached 5 patches (split up for ease of review) to plperl.c. 1. Two minor cleanups: - We don't need to call hv_exists+hv_fetch; we should just check the return value of hv_fetch. - newSVpv("undef",0) is the string "undef", not a real undef. 2. This should fix the bug Andrew Dunstan described in a recent -hackers post. It replaces three bogus "eval_pv(key, 0)" calls with newSVpv, and eliminates another redundant hv_exists+hv_fetch pair. 3. plperl_build_tuple_argument builds up a string of Perl code to create a hash representing the tuple. This patch creates the hash directly. 4. Another minor cleanup: replace a couple of av_store()s with av_push. 5. Analogous to #3 for plperl_trigger_build_args. This patch removes the static sv_add_tuple_value function, which does much the same as two other utility functions defined later, and merges the functionality into plperl_hash_from_tuple. I have tested the patches to the best of my limited ability, but I would appreciate it very much if someone else could review and test them too. (Thanks to Andrew and David Fetter for their help with some testing.) Abhijit Menon-Sen
2004-10-15 19:08:26 +02:00
plperl: Correctly handle empty arrays in plperl_ref_from_pg_array. plperl_ref_from_pg_array() didn't consider the case that postgrs arrays can have 0 dimensions (when they're empty) and accessed the first dimension without a check. Fix that by special casing the empty array case. Author: Alex Hunsaker Reported-By: Andres Freund / valgrind / buildfarm animal skink Discussion: 20160308063240.usnzg6bsbjrne667@alap3.anarazel.de Backpatch: 9.1-
2016-03-08 22:33:24 +01:00
/* we should only be called when we have something to split */
Assert(info->ndims > 0);
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
/* since this function recurses, it could be driven to stack overflow */
check_stack_depth();
/*
* Base case, return a reference to a single-dimensional array
*/
if (nest >= info->ndims - 1)
return make_array_ref(info, first, last);
result = newAV();
for (i = first; i < last; i += info->nelems[nest + 1])
{
/* Recursively form references to arrays of lower dimensions */
SV *ref = split_array(info, i, i + info->nelems[nest + 1], nest + 1);
av_push(result, ref);
}
return newRV_noinc((SV *) result);
}
/*
* Create a Perl reference from a one-dimensional C array, converting
* composite type elements to hash references.
*/
static SV *
make_array_ref(plperl_array_info *info, int first, int last)
{
PL/Perl portability fix: avoid including XSUB.h in plperl.c. In Perl builds that define PERL_IMPLICIT_SYS, XSUB.h defines macros that replace a whole lot of basic libc functions with Perl functions. We can't tolerate that in plperl.c; it breaks at least PG_TRY and probably other stuff. The core idea of this patch is to include XSUB.h only in the .xs files where it's really needed, and to move any code broken by PERL_IMPLICIT_SYS out of the .xs files and into plperl.c. The reason this hasn't been a problem before is that our build techniques did not result in PERL_IMPLICIT_SYS appearing as a #define in PL/Perl, even on some platforms where Perl thinks it is defined. That's about to change in order to fix a nasty portability issue, so we need this work to make the code safe for that. Rather unaccountably, the Perl people chose XSUB.h as the place to provide the versions of the aTHX/aTHX_ macros that are needed by code that's not explicitly aware of the MULTIPLICITY API conventions. Hence, just removing XSUB.h from plperl.c fails miserably. But we can work around that by defining PERL_NO_GET_CONTEXT (which would make the relevant stanza of XSUB.h a no-op anyway). As explained in perlguts.pod, that means we need to add a "dTHX" macro call in every C function that calls a Perl API function. In most of them we just add this at the top; but since the macro fetches the current Perl interpreter pointer, more care is needed in functions that switch the active interpreter. Lack of the macro is easily recognized since it results in bleats about "my_perl" not being defined. (A nice side benefit of this is that it significantly reduces the number of fetches of the current interpreter pointer. On my machine, plperl.so gets more than 10% smaller, and there's probably some performance win too. We could reduce the number of fetches still more by decorating the code with pTHX_/aTHX_ macros to pass the interpreter pointer around, as explained by perlguts.pod; but that's a task for another day.) Formatting note: pgindent seems happy to treat "dTHX;" as a declaration so long as it's the first thing after the left brace, as we'd already observed with respect to the similar macro "dSP;". If you try to put it later in a set of declarations, pgindent puts ugly extra space around it. Having removed XSUB.h from plperl.c, we need only move the support functions for spi_return_next and util_elog (both of which use PG_TRY) out of the .xs files and into plperl.c. This seems sufficient to avoid the known problems caused by PERL_IMPLICIT_SYS, although we could move more code if additional issues emerge. This will need to be back-patched, but first let's see what the buildfarm makes of it. Patch by me, with some help from Ashutosh Sharma Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
2017-07-28 18:25:43 +02:00
dTHX;
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
int i;
AV *result = newAV();
for (i = first; i < last; i++)
{
if (info->nulls[i])
Remove usage of &PL_sv_undef in hashes and arrays According to perlguts, &PL_sv_undef is not the right thing to use in those cases because it doesn't behave the same way as an undef value via Perl code. Seems the intuitive way to deal with undef values is subtly enough broken that it's hard to notice when misused. The broken uses got inadvertently introduced in commit 87bb2ade2ce646083f39d5ab3e3307490211ad04 by Alexey Klyukin, Alex Hunsaker and myself on 2011-02-17; no backpatch is necessary. Per testing report from Greg Mullane. Author: Alex Hunsaker
2011-05-30 18:15:13 +02:00
{
/*
* We can't use &PL_sv_undef here. See "AVs, HVs and undefined
* values" in perlguts.
*/
av_push(result, newSV(0));
}
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
else
{
Datum itemvalue = info->elements[i];
At 2005-05-21 20:18:50 +0530, ams@oryx.com wrote: > > > The second issue is where plperl returns a large result set. I have attached the following seven patches to address this problem: 1. Trivial. Replaces some errant spaces with tabs. 2. Trivial. Fixes the spelling of Jan's name, and gets rid of many inane, useless, annoying, and often misleading comments. Here's a sample: "plperl_init_all() - Initialize all". (I have tried to add some useful comments here and there, and will continue to do so now and again.) 3. Trivial. Splits up some long lines. 4. Converts SRFs in PL/Perl to use a Tuplestore and SFRM_Materialize to return the result set, based on the PL/PgSQL model. There are two major consequences: result sets will spill to disk when they can no longer fit in work_mem; and "select foo_srf()" no longer works. (I didn't lose sleep over the latter, since that form is not valid in PL/PgSQL, and it's not documented in PL/Perl.) 5. Trivial, but important. Fixes use of "undef" instead of undef. This would cause empty functions to fail in bizarre ways. I suspect that there's still another (old) bug here. I'll investigate further. 6. Moves the majority of (4) out into a new plperl_return_next() function, to make it possible to expose the functionality to Perl; cleans up some of the code besides. 7. Add an spi_return_next function for use in Perl code. If you want to apply the patches and try them out, 8-composite.diff is what you should use. (Note: my patches depend upon Andrew's use-strict and %_SHARED patches being applied.) Here's something to try: create or replace function foo() returns setof record as $$ $i = 0; for ("World", "PostgreSQL", "PL/Perl") { spi_return_next({f1=>++$i, f2=>'Hello', f3=>$_}); } return; $$ language plperl; select * from foo() as (f1 integer, f2 text, f3 text); (Many thanks to Andrews Dunstan and Supernews for their help.) Abhijit Menon-Sen
2005-06-04 22:33:06 +02:00
Add transforms feature This provides a mechanism for specifying conversions between SQL data types and procedural languages. As examples, there are transforms for hstore and ltree for PL/Perl and PL/Python. reviews by Pavel Stěhule and Andres Freund
2015-04-26 16:33:14 +02:00
if (info->transform_proc.fn_oid)
av_push(result, (SV *) DatumGetPointer(FunctionCall1(&info->transform_proc, itemvalue)));
else if (info->elem_is_rowtype)
/* Handle composite type elements */
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
av_push(result, plperl_hash_from_datum(itemvalue));
else
{
char *val = OutputFunctionCall(&info->proc, itemvalue);
av_push(result, cstr2sv(val));
}
}
}
return newRV_noinc((SV *) result);
}
/* Set up the arguments for a trigger call. */
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
static SV *
plperl_trigger_build_args(FunctionCallInfo fcinfo)
{
PL/Perl portability fix: avoid including XSUB.h in plperl.c. In Perl builds that define PERL_IMPLICIT_SYS, XSUB.h defines macros that replace a whole lot of basic libc functions with Perl functions. We can't tolerate that in plperl.c; it breaks at least PG_TRY and probably other stuff. The core idea of this patch is to include XSUB.h only in the .xs files where it's really needed, and to move any code broken by PERL_IMPLICIT_SYS out of the .xs files and into plperl.c. The reason this hasn't been a problem before is that our build techniques did not result in PERL_IMPLICIT_SYS appearing as a #define in PL/Perl, even on some platforms where Perl thinks it is defined. That's about to change in order to fix a nasty portability issue, so we need this work to make the code safe for that. Rather unaccountably, the Perl people chose XSUB.h as the place to provide the versions of the aTHX/aTHX_ macros that are needed by code that's not explicitly aware of the MULTIPLICITY API conventions. Hence, just removing XSUB.h from plperl.c fails miserably. But we can work around that by defining PERL_NO_GET_CONTEXT (which would make the relevant stanza of XSUB.h a no-op anyway). As explained in perlguts.pod, that means we need to add a "dTHX" macro call in every C function that calls a Perl API function. In most of them we just add this at the top; but since the macro fetches the current Perl interpreter pointer, more care is needed in functions that switch the active interpreter. Lack of the macro is easily recognized since it results in bleats about "my_perl" not being defined. (A nice side benefit of this is that it significantly reduces the number of fetches of the current interpreter pointer. On my machine, plperl.so gets more than 10% smaller, and there's probably some performance win too. We could reduce the number of fetches still more by decorating the code with pTHX_/aTHX_ macros to pass the interpreter pointer around, as explained by perlguts.pod; but that's a task for another day.) Formatting note: pgindent seems happy to treat "dTHX;" as a declaration so long as it's the first thing after the left brace, as we'd already observed with respect to the similar macro "dSP;". If you try to put it later in a set of declarations, pgindent puts ugly extra space around it. Having removed XSUB.h from plperl.c, we need only move the support functions for spi_return_next and util_elog (both of which use PG_TRY) out of the .xs files and into plperl.c. This seems sufficient to avoid the known problems caused by PERL_IMPLICIT_SYS, although we could move more code if additional issues emerge. This will need to be back-patched, but first let's see what the buildfarm makes of it. Patch by me, with some help from Ashutosh Sharma Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
2017-07-28 18:25:43 +02:00
dTHX;
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
TriggerData *tdata;
TupleDesc tupdesc;
Further plperl cleanup: be more paranoid about checking the type of data returned from Perl. Consolidate multiple bits of code to convert a Perl hash to a tuple, and drive the conversion off the keys present in the hash rather than the tuple column names, so we detect error if the hash contains keys it shouldn't. (This means keys not in the hash will silently default to NULL, which seems ok to me.) Fix a bunch of reference-count leaks too.
2004-11-23 01:21:24 +01:00
int i;
I have attached 5 patches (split up for ease of review) to plperl.c. 1. Two minor cleanups: - We don't need to call hv_exists+hv_fetch; we should just check the return value of hv_fetch. - newSVpv("undef",0) is the string "undef", not a real undef. 2. This should fix the bug Andrew Dunstan described in a recent -hackers post. It replaces three bogus "eval_pv(key, 0)" calls with newSVpv, and eliminates another redundant hv_exists+hv_fetch pair. 3. plperl_build_tuple_argument builds up a string of Perl code to create a hash representing the tuple. This patch creates the hash directly. 4. Another minor cleanup: replace a couple of av_store()s with av_push. 5. Analogous to #3 for plperl_trigger_build_args. This patch removes the static sv_add_tuple_value function, which does much the same as two other utility functions defined later, and merges the functionality into plperl_hash_from_tuple. I have tested the patches to the best of my limited ability, but I would appreciate it very much if someone else could review and test them too. (Thanks to Andrew and David Fetter for their help with some testing.) Abhijit Menon-Sen
2004-10-15 19:08:26 +02:00
char *level;
char *event;
char *relid;
char *when;
HV *hv;
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
I have attached 5 patches (split up for ease of review) to plperl.c. 1. Two minor cleanups: - We don't need to call hv_exists+hv_fetch; we should just check the return value of hv_fetch. - newSVpv("undef",0) is the string "undef", not a real undef. 2. This should fix the bug Andrew Dunstan described in a recent -hackers post. It replaces three bogus "eval_pv(key, 0)" calls with newSVpv, and eliminates another redundant hv_exists+hv_fetch pair. 3. plperl_build_tuple_argument builds up a string of Perl code to create a hash representing the tuple. This patch creates the hash directly. 4. Another minor cleanup: replace a couple of av_store()s with av_push. 5. Analogous to #3 for plperl_trigger_build_args. This patch removes the static sv_add_tuple_value function, which does much the same as two other utility functions defined later, and merges the functionality into plperl_hash_from_tuple. I have tested the patches to the best of my limited ability, but I would appreciate it very much if someone else could review and test them too. (Thanks to Andrew and David Fetter for their help with some testing.) Abhijit Menon-Sen
2004-10-15 19:08:26 +02:00
hv = newHV();
Various small improvements and cleanups for PL/Perl. - Allow (ineffective) use of 'require' in plperl If the required module is not already loaded then it dies. So "use strict;" now works in plperl. - Pre-load the feature module if perl >= 5.10. So "use feature :5.10;" now works in plperl. - Stored procedure subs are now given names. The names are not visible in ordinary use, but they make tools like Devel::NYTProf and Devel::Cover much more useful. - Simplified and generalized the subroutine creation code. Now one code path for generating sub source code, not four. Can generate multiple 'use' statements with specific imports (which handles plperl.use_strict currently and can easily be extended to handle a plperl.use_feature=':5.12' in future). - Disallows use of Safe version 2.20 which is broken for PL/Perl. http://rt.perl.org/rt3/Ticket/Display.html?id=72068 - Assorted minor optimizations by pre-growing data structures. Patch from Tim Bunce, reviewed by Alex Hunsaker.
2010-01-27 00:11:56 +01:00
hv_ksplit(hv, 12); /* pre-grow the hash */
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
tdata = (TriggerData *) fcinfo->context;
tupdesc = tdata->tg_relation->rd_att;
Further plperl cleanup: be more paranoid about checking the type of data returned from Perl. Consolidate multiple bits of code to convert a Perl hash to a tuple, and drive the conversion off the keys present in the hash rather than the tuple column names, so we detect error if the hash contains keys it shouldn't. (This means keys not in the hash will silently default to NULL, which seems ok to me.) Fix a bunch of reference-count leaks too.
2004-11-23 01:21:24 +01:00
relid = DatumGetCString(DirectFunctionCall1(oidout,
ObjectIdGetDatum(tdata->tg_relation->rd_id)));
I have attached 5 patches (split up for ease of review) to plperl.c. 1. Two minor cleanups: - We don't need to call hv_exists+hv_fetch; we should just check the return value of hv_fetch. - newSVpv("undef",0) is the string "undef", not a real undef. 2. This should fix the bug Andrew Dunstan described in a recent -hackers post. It replaces three bogus "eval_pv(key, 0)" calls with newSVpv, and eliminates another redundant hv_exists+hv_fetch pair. 3. plperl_build_tuple_argument builds up a string of Perl code to create a hash representing the tuple. This patch creates the hash directly. 4. Another minor cleanup: replace a couple of av_store()s with av_push. 5. Analogous to #3 for plperl_trigger_build_args. This patch removes the static sv_add_tuple_value function, which does much the same as two other utility functions defined later, and merges the functionality into plperl_hash_from_tuple. I have tested the patches to the best of my limited ability, but I would appreciate it very much if someone else could review and test them too. (Thanks to Andrew and David Fetter for their help with some testing.) Abhijit Menon-Sen
2004-10-15 19:08:26 +02:00
Force strings passed to and from plperl to be in UTF8 encoding. String are converted to UTF8 on the way into perl and to the database encoding on the way back. This avoids a number of observed anomalies, and ensures Perl a consistent view of the world. Some minor code cleanups are also accomplished. Alex Hunsaker, reviewed by Andy Colson.
2011-02-06 23:29:26 +01:00
hv_store_string(hv, "name", cstr2sv(tdata->tg_trigger->tgname));
hv_store_string(hv, "relid", cstr2sv(relid));
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
Generated columns This is an SQL-standard feature that allows creating columns that are computed from expressions rather than assigned, similar to a view or materialized view but on a column basis. This implements one kind of generated column: stored (computed on write). Another kind, virtual (computed on read), is planned for the future, and some room is left for it. Reviewed-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Pavel Stehule <pavel.stehule@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/b151f851-4019-bdb1-699e-ebab07d2f40a@2ndquadrant.com
2019-03-30 08:13:09 +01:00
/*
* Note: In BEFORE trigger, stored generated columns are not computed yet,
* so don't make them accessible in NEW row.
*/
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
if (TRIGGER_FIRED_BY_INSERT(tdata->tg_event))
{
I have attached 5 patches (split up for ease of review) to plperl.c. 1. Two minor cleanups: - We don't need to call hv_exists+hv_fetch; we should just check the return value of hv_fetch. - newSVpv("undef",0) is the string "undef", not a real undef. 2. This should fix the bug Andrew Dunstan described in a recent -hackers post. It replaces three bogus "eval_pv(key, 0)" calls with newSVpv, and eliminates another redundant hv_exists+hv_fetch pair. 3. plperl_build_tuple_argument builds up a string of Perl code to create a hash representing the tuple. This patch creates the hash directly. 4. Another minor cleanup: replace a couple of av_store()s with av_push. 5. Analogous to #3 for plperl_trigger_build_args. This patch removes the static sv_add_tuple_value function, which does much the same as two other utility functions defined later, and merges the functionality into plperl_hash_from_tuple. I have tested the patches to the best of my limited ability, but I would appreciate it very much if someone else could review and test them too. (Thanks to Andrew and David Fetter for their help with some testing.) Abhijit Menon-Sen
2004-10-15 19:08:26 +02:00
event = "INSERT";
plperl trigger handler tried to fetch new/old tuples even when fired as a statement trigger :-(. Per report from Sokolov Yura.
2005-01-14 17:25:42 +01:00
if (TRIGGER_FIRED_FOR_ROW(tdata->tg_event))
Adjust plperl to ensure that all strings and hash keys passed to Perl are marked as UTF8 when the database encoding is UTF8. This should avoid inconsistencies like that exhibited in bug #2683 from Vitali Stupin.
2006-10-15 20:56:39 +02:00
hv_store_string(hv, "new",
plperl_hash_from_tuple(tdata->tg_trigtuple,
Generated columns This is an SQL-standard feature that allows creating columns that are computed from expressions rather than assigned, similar to a view or materialized view but on a column basis. This implements one kind of generated column: stored (computed on write). Another kind, virtual (computed on read), is planned for the future, and some room is left for it. Reviewed-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Pavel Stehule <pavel.stehule@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/b151f851-4019-bdb1-699e-ebab07d2f40a@2ndquadrant.com
2019-03-30 08:13:09 +01:00
tupdesc,
!TRIGGER_FIRED_BEFORE(tdata->tg_event)));
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
}
else if (TRIGGER_FIRED_BY_DELETE(tdata->tg_event))
{
I have attached 5 patches (split up for ease of review) to plperl.c. 1. Two minor cleanups: - We don't need to call hv_exists+hv_fetch; we should just check the return value of hv_fetch. - newSVpv("undef",0) is the string "undef", not a real undef. 2. This should fix the bug Andrew Dunstan described in a recent -hackers post. It replaces three bogus "eval_pv(key, 0)" calls with newSVpv, and eliminates another redundant hv_exists+hv_fetch pair. 3. plperl_build_tuple_argument builds up a string of Perl code to create a hash representing the tuple. This patch creates the hash directly. 4. Another minor cleanup: replace a couple of av_store()s with av_push. 5. Analogous to #3 for plperl_trigger_build_args. This patch removes the static sv_add_tuple_value function, which does much the same as two other utility functions defined later, and merges the functionality into plperl_hash_from_tuple. I have tested the patches to the best of my limited ability, but I would appreciate it very much if someone else could review and test them too. (Thanks to Andrew and David Fetter for their help with some testing.) Abhijit Menon-Sen
2004-10-15 19:08:26 +02:00
event = "DELETE";
plperl trigger handler tried to fetch new/old tuples even when fired as a statement trigger :-(. Per report from Sokolov Yura.
2005-01-14 17:25:42 +01:00
if (TRIGGER_FIRED_FOR_ROW(tdata->tg_event))
Adjust plperl to ensure that all strings and hash keys passed to Perl are marked as UTF8 when the database encoding is UTF8. This should avoid inconsistencies like that exhibited in bug #2683 from Vitali Stupin.
2006-10-15 20:56:39 +02:00
hv_store_string(hv, "old",
plperl_hash_from_tuple(tdata->tg_trigtuple,
Generated columns This is an SQL-standard feature that allows creating columns that are computed from expressions rather than assigned, similar to a view or materialized view but on a column basis. This implements one kind of generated column: stored (computed on write). Another kind, virtual (computed on read), is planned for the future, and some room is left for it. Reviewed-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Pavel Stehule <pavel.stehule@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/b151f851-4019-bdb1-699e-ebab07d2f40a@2ndquadrant.com
2019-03-30 08:13:09 +01:00
tupdesc,
true));
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
}
else if (TRIGGER_FIRED_BY_UPDATE(tdata->tg_event))
{
I have attached 5 patches (split up for ease of review) to plperl.c. 1. Two minor cleanups: - We don't need to call hv_exists+hv_fetch; we should just check the return value of hv_fetch. - newSVpv("undef",0) is the string "undef", not a real undef. 2. This should fix the bug Andrew Dunstan described in a recent -hackers post. It replaces three bogus "eval_pv(key, 0)" calls with newSVpv, and eliminates another redundant hv_exists+hv_fetch pair. 3. plperl_build_tuple_argument builds up a string of Perl code to create a hash representing the tuple. This patch creates the hash directly. 4. Another minor cleanup: replace a couple of av_store()s with av_push. 5. Analogous to #3 for plperl_trigger_build_args. This patch removes the static sv_add_tuple_value function, which does much the same as two other utility functions defined later, and merges the functionality into plperl_hash_from_tuple. I have tested the patches to the best of my limited ability, but I would appreciate it very much if someone else could review and test them too. (Thanks to Andrew and David Fetter for their help with some testing.) Abhijit Menon-Sen
2004-10-15 19:08:26 +02:00
event = "UPDATE";
plperl trigger handler tried to fetch new/old tuples even when fired as a statement trigger :-(. Per report from Sokolov Yura.
2005-01-14 17:25:42 +01:00
if (TRIGGER_FIRED_FOR_ROW(tdata->tg_event))
{
Adjust plperl to ensure that all strings and hash keys passed to Perl are marked as UTF8 when the database encoding is UTF8. This should avoid inconsistencies like that exhibited in bug #2683 from Vitali Stupin.
2006-10-15 20:56:39 +02:00
hv_store_string(hv, "old",
plperl_hash_from_tuple(tdata->tg_trigtuple,
Generated columns This is an SQL-standard feature that allows creating columns that are computed from expressions rather than assigned, similar to a view or materialized view but on a column basis. This implements one kind of generated column: stored (computed on write). Another kind, virtual (computed on read), is planned for the future, and some room is left for it. Reviewed-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Pavel Stehule <pavel.stehule@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/b151f851-4019-bdb1-699e-ebab07d2f40a@2ndquadrant.com
2019-03-30 08:13:09 +01:00
tupdesc,
true));
Adjust plperl to ensure that all strings and hash keys passed to Perl are marked as UTF8 when the database encoding is UTF8. This should avoid inconsistencies like that exhibited in bug #2683 from Vitali Stupin.
2006-10-15 20:56:39 +02:00
hv_store_string(hv, "new",
plperl_hash_from_tuple(tdata->tg_newtuple,
Generated columns This is an SQL-standard feature that allows creating columns that are computed from expressions rather than assigned, similar to a view or materialized view but on a column basis. This implements one kind of generated column: stored (computed on write). Another kind, virtual (computed on read), is planned for the future, and some room is left for it. Reviewed-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Pavel Stehule <pavel.stehule@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/b151f851-4019-bdb1-699e-ebab07d2f40a@2ndquadrant.com
2019-03-30 08:13:09 +01:00
tupdesc,
!TRIGGER_FIRED_BEFORE(tdata->tg_event)));
plperl trigger handler tried to fetch new/old tuples even when fired as a statement trigger :-(. Per report from Sokolov Yura.
2005-01-14 17:25:42 +01:00
}
I have attached 5 patches (split up for ease of review) to plperl.c. 1. Two minor cleanups: - We don't need to call hv_exists+hv_fetch; we should just check the return value of hv_fetch. - newSVpv("undef",0) is the string "undef", not a real undef. 2. This should fix the bug Andrew Dunstan described in a recent -hackers post. It replaces three bogus "eval_pv(key, 0)" calls with newSVpv, and eliminates another redundant hv_exists+hv_fetch pair. 3. plperl_build_tuple_argument builds up a string of Perl code to create a hash representing the tuple. This patch creates the hash directly. 4. Another minor cleanup: replace a couple of av_store()s with av_push. 5. Analogous to #3 for plperl_trigger_build_args. This patch removes the static sv_add_tuple_value function, which does much the same as two other utility functions defined later, and merges the functionality into plperl_hash_from_tuple. I have tested the patches to the best of my limited ability, but I would appreciate it very much if someone else could review and test them too. (Thanks to Andrew and David Fetter for their help with some testing.) Abhijit Menon-Sen
2004-10-15 19:08:26 +02:00
}
Support statement-level ON TRUNCATE triggers. Simon Riggs
2008-03-28 01:21:56 +01:00
else if (TRIGGER_FIRED_BY_TRUNCATE(tdata->tg_event))
event = "TRUNCATE";
plperl trigger handler tried to fetch new/old tuples even when fired as a statement trigger :-(. Per report from Sokolov Yura.
2005-01-14 17:25:42 +01:00
else
I have attached 5 patches (split up for ease of review) to plperl.c. 1. Two minor cleanups: - We don't need to call hv_exists+hv_fetch; we should just check the return value of hv_fetch. - newSVpv("undef",0) is the string "undef", not a real undef. 2. This should fix the bug Andrew Dunstan described in a recent -hackers post. It replaces three bogus "eval_pv(key, 0)" calls with newSVpv, and eliminates another redundant hv_exists+hv_fetch pair. 3. plperl_build_tuple_argument builds up a string of Perl code to create a hash representing the tuple. This patch creates the hash directly. 4. Another minor cleanup: replace a couple of av_store()s with av_push. 5. Analogous to #3 for plperl_trigger_build_args. This patch removes the static sv_add_tuple_value function, which does much the same as two other utility functions defined later, and merges the functionality into plperl_hash_from_tuple. I have tested the patches to the best of my limited ability, but I would appreciate it very much if someone else could review and test them too. (Thanks to Andrew and David Fetter for their help with some testing.) Abhijit Menon-Sen
2004-10-15 19:08:26 +02:00
event = "UNKNOWN";
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
Force strings passed to and from plperl to be in UTF8 encoding. String are converted to UTF8 on the way into perl and to the database encoding on the way back. This avoids a number of observed anomalies, and ensures Perl a consistent view of the world. Some minor code cleanups are also accomplished. Alex Hunsaker, reviewed by Andy Colson.
2011-02-06 23:29:26 +01:00
hv_store_string(hv, "event", cstr2sv(event));
Adjust plperl to ensure that all strings and hash keys passed to Perl are marked as UTF8 when the database encoding is UTF8. This should avoid inconsistencies like that exhibited in bug #2683 from Vitali Stupin.
2006-10-15 20:56:39 +02:00
hv_store_string(hv, "argc", newSViv(tdata->tg_trigger->tgnargs));
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
plperl trigger handler tried to fetch new/old tuples even when fired as a statement trigger :-(. Per report from Sokolov Yura.
2005-01-14 17:25:42 +01:00
if (tdata->tg_trigger->tgnargs > 0)
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
{
I have attached 5 patches (split up for ease of review) to plperl.c. 1. Two minor cleanups: - We don't need to call hv_exists+hv_fetch; we should just check the return value of hv_fetch. - newSVpv("undef",0) is the string "undef", not a real undef. 2. This should fix the bug Andrew Dunstan described in a recent -hackers post. It replaces three bogus "eval_pv(key, 0)" calls with newSVpv, and eliminates another redundant hv_exists+hv_fetch pair. 3. plperl_build_tuple_argument builds up a string of Perl code to create a hash representing the tuple. This patch creates the hash directly. 4. Another minor cleanup: replace a couple of av_store()s with av_push. 5. Analogous to #3 for plperl_trigger_build_args. This patch removes the static sv_add_tuple_value function, which does much the same as two other utility functions defined later, and merges the functionality into plperl_hash_from_tuple. I have tested the patches to the best of my limited ability, but I would appreciate it very much if someone else could review and test them too. (Thanks to Andrew and David Fetter for their help with some testing.) Abhijit Menon-Sen
2004-10-15 19:08:26 +02:00
AV *av = newAV();
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
Various small improvements and cleanups for PL/Perl. - Allow (ineffective) use of 'require' in plperl If the required module is not already loaded then it dies. So "use strict;" now works in plperl. - Pre-load the feature module if perl >= 5.10. So "use feature :5.10;" now works in plperl. - Stored procedure subs are now given names. The names are not visible in ordinary use, but they make tools like Devel::NYTProf and Devel::Cover much more useful. - Simplified and generalized the subroutine creation code. Now one code path for generating sub source code, not four. Can generate multiple 'use' statements with specific imports (which handles plperl.use_strict currently and can easily be extended to handle a plperl.use_feature=':5.12' in future). - Disallows use of Safe version 2.20 which is broken for PL/Perl. http://rt.perl.org/rt3/Ticket/Display.html?id=72068 - Assorted minor optimizations by pre-growing data structures. Patch from Tim Bunce, reviewed by Alex Hunsaker.
2010-01-27 00:11:56 +01:00
av_extend(av, tdata->tg_trigger->tgnargs);
I have attached 5 patches (split up for ease of review) to plperl.c. 1. Two minor cleanups: - We don't need to call hv_exists+hv_fetch; we should just check the return value of hv_fetch. - newSVpv("undef",0) is the string "undef", not a real undef. 2. This should fix the bug Andrew Dunstan described in a recent -hackers post. It replaces three bogus "eval_pv(key, 0)" calls with newSVpv, and eliminates another redundant hv_exists+hv_fetch pair. 3. plperl_build_tuple_argument builds up a string of Perl code to create a hash representing the tuple. This patch creates the hash directly. 4. Another minor cleanup: replace a couple of av_store()s with av_push. 5. Analogous to #3 for plperl_trigger_build_args. This patch removes the static sv_add_tuple_value function, which does much the same as two other utility functions defined later, and merges the functionality into plperl_hash_from_tuple. I have tested the patches to the best of my limited ability, but I would appreciate it very much if someone else could review and test them too. (Thanks to Andrew and David Fetter for their help with some testing.) Abhijit Menon-Sen
2004-10-15 19:08:26 +02:00
for (i = 0; i < tdata->tg_trigger->tgnargs; i++)
Force strings passed to and from plperl to be in UTF8 encoding. String are converted to UTF8 on the way into perl and to the database encoding on the way back. This avoids a number of observed anomalies, and ensures Perl a consistent view of the world. Some minor code cleanups are also accomplished. Alex Hunsaker, reviewed by Andy Colson.
2011-02-06 23:29:26 +01:00
av_push(av, cstr2sv(tdata->tg_trigger->tgargs[i]));
Adjust plperl to ensure that all strings and hash keys passed to Perl are marked as UTF8 when the database encoding is UTF8. This should avoid inconsistencies like that exhibited in bug #2683 from Vitali Stupin.
2006-10-15 20:56:39 +02:00
hv_store_string(hv, "args", newRV_noinc((SV *) av));
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
}
I have attached 5 patches (split up for ease of review) to plperl.c. 1. Two minor cleanups: - We don't need to call hv_exists+hv_fetch; we should just check the return value of hv_fetch. - newSVpv("undef",0) is the string "undef", not a real undef. 2. This should fix the bug Andrew Dunstan described in a recent -hackers post. It replaces three bogus "eval_pv(key, 0)" calls with newSVpv, and eliminates another redundant hv_exists+hv_fetch pair. 3. plperl_build_tuple_argument builds up a string of Perl code to create a hash representing the tuple. This patch creates the hash directly. 4. Another minor cleanup: replace a couple of av_store()s with av_push. 5. Analogous to #3 for plperl_trigger_build_args. This patch removes the static sv_add_tuple_value function, which does much the same as two other utility functions defined later, and merges the functionality into plperl_hash_from_tuple. I have tested the patches to the best of my limited ability, but I would appreciate it very much if someone else could review and test them too. (Thanks to Andrew and David Fetter for their help with some testing.) Abhijit Menon-Sen
2004-10-15 19:08:26 +02:00
Adjust plperl to ensure that all strings and hash keys passed to Perl are marked as UTF8 when the database encoding is UTF8. This should avoid inconsistencies like that exhibited in bug #2683 from Vitali Stupin.
2006-10-15 20:56:39 +02:00
hv_store_string(hv, "relname",
Force strings passed to and from plperl to be in UTF8 encoding. String are converted to UTF8 on the way into perl and to the database encoding on the way back. This avoids a number of observed anomalies, and ensures Perl a consistent view of the world. Some minor code cleanups are also accomplished. Alex Hunsaker, reviewed by Andy Colson.
2011-02-06 23:29:26 +01:00
cstr2sv(SPI_getrelname(tdata->tg_relation)));
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
Adjust plperl to ensure that all strings and hash keys passed to Perl are marked as UTF8 when the database encoding is UTF8. This should avoid inconsistencies like that exhibited in bug #2683 from Vitali Stupin.
2006-10-15 20:56:39 +02:00
hv_store_string(hv, "table_name",
Force strings passed to and from plperl to be in UTF8 encoding. String are converted to UTF8 on the way into perl and to the database encoding on the way back. This avoids a number of observed anomalies, and ensures Perl a consistent view of the world. Some minor code cleanups are also accomplished. Alex Hunsaker, reviewed by Andy Colson.
2011-02-06 23:29:26 +01:00
cstr2sv(SPI_getrelname(tdata->tg_relation)));
Add table_name and table_schema to plperl trigger data. relname is kept but now deprecated. Patch from Adam Sjøgren. Add regression test to show plperl trigger data (Andrew). TBD: apply similar changes to plpgsql, plpython and pltcl.
2006-05-26 19:34:16 +02:00
Adjust plperl to ensure that all strings and hash keys passed to Perl are marked as UTF8 when the database encoding is UTF8. This should avoid inconsistencies like that exhibited in bug #2683 from Vitali Stupin.
2006-10-15 20:56:39 +02:00
hv_store_string(hv, "table_schema",
Force strings passed to and from plperl to be in UTF8 encoding. String are converted to UTF8 on the way into perl and to the database encoding on the way back. This avoids a number of observed anomalies, and ensures Perl a consistent view of the world. Some minor code cleanups are also accomplished. Alex Hunsaker, reviewed by Andy Colson.
2011-02-06 23:29:26 +01:00
cstr2sv(SPI_getnspname(tdata->tg_relation)));
Add table_name and table_schema to plperl trigger data. relname is kept but now deprecated. Patch from Adam Sjøgren. Add regression test to show plperl trigger data (Andrew). TBD: apply similar changes to plpgsql, plpython and pltcl.
2006-05-26 19:34:16 +02:00
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
if (TRIGGER_FIRED_BEFORE(tdata->tg_event))
I have attached 5 patches (split up for ease of review) to plperl.c. 1. Two minor cleanups: - We don't need to call hv_exists+hv_fetch; we should just check the return value of hv_fetch. - newSVpv("undef",0) is the string "undef", not a real undef. 2. This should fix the bug Andrew Dunstan described in a recent -hackers post. It replaces three bogus "eval_pv(key, 0)" calls with newSVpv, and eliminates another redundant hv_exists+hv_fetch pair. 3. plperl_build_tuple_argument builds up a string of Perl code to create a hash representing the tuple. This patch creates the hash directly. 4. Another minor cleanup: replace a couple of av_store()s with av_push. 5. Analogous to #3 for plperl_trigger_build_args. This patch removes the static sv_add_tuple_value function, which does much the same as two other utility functions defined later, and merges the functionality into plperl_hash_from_tuple. I have tested the patches to the best of my limited ability, but I would appreciate it very much if someone else could review and test them too. (Thanks to Andrew and David Fetter for their help with some testing.) Abhijit Menon-Sen
2004-10-15 19:08:26 +02:00
when = "BEFORE";
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
else if (TRIGGER_FIRED_AFTER(tdata->tg_event))
I have attached 5 patches (split up for ease of review) to plperl.c. 1. Two minor cleanups: - We don't need to call hv_exists+hv_fetch; we should just check the return value of hv_fetch. - newSVpv("undef",0) is the string "undef", not a real undef. 2. This should fix the bug Andrew Dunstan described in a recent -hackers post. It replaces three bogus "eval_pv(key, 0)" calls with newSVpv, and eliminates another redundant hv_exists+hv_fetch pair. 3. plperl_build_tuple_argument builds up a string of Perl code to create a hash representing the tuple. This patch creates the hash directly. 4. Another minor cleanup: replace a couple of av_store()s with av_push. 5. Analogous to #3 for plperl_trigger_build_args. This patch removes the static sv_add_tuple_value function, which does much the same as two other utility functions defined later, and merges the functionality into plperl_hash_from_tuple. I have tested the patches to the best of my limited ability, but I would appreciate it very much if someone else could review and test them too. (Thanks to Andrew and David Fetter for their help with some testing.) Abhijit Menon-Sen
2004-10-15 19:08:26 +02:00
when = "AFTER";
Support triggers on views. This patch adds the SQL-standard concept of an INSTEAD OF trigger, which is fired instead of performing a physical insert/update/delete. The trigger function is passed the entire old and/or new rows of the view, and must figure out what to do to the underlying tables to implement the update. So this feature can be used to implement updatable views using trigger programming style rather than rule hacking. In passing, this patch corrects the names of some columns in the information_schema.triggers view. It seems the SQL committee renamed them somewhere between SQL:99 and SQL:2003. Dean Rasheed, reviewed by Bernd Helmle; some additional hacking by me.
2010-10-10 19:43:33 +02:00
else if (TRIGGER_FIRED_INSTEAD(tdata->tg_event))
when = "INSTEAD OF";
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
else
I have attached 5 patches (split up for ease of review) to plperl.c. 1. Two minor cleanups: - We don't need to call hv_exists+hv_fetch; we should just check the return value of hv_fetch. - newSVpv("undef",0) is the string "undef", not a real undef. 2. This should fix the bug Andrew Dunstan described in a recent -hackers post. It replaces three bogus "eval_pv(key, 0)" calls with newSVpv, and eliminates another redundant hv_exists+hv_fetch pair. 3. plperl_build_tuple_argument builds up a string of Perl code to create a hash representing the tuple. This patch creates the hash directly. 4. Another minor cleanup: replace a couple of av_store()s with av_push. 5. Analogous to #3 for plperl_trigger_build_args. This patch removes the static sv_add_tuple_value function, which does much the same as two other utility functions defined later, and merges the functionality into plperl_hash_from_tuple. I have tested the patches to the best of my limited ability, but I would appreciate it very much if someone else could review and test them too. (Thanks to Andrew and David Fetter for their help with some testing.) Abhijit Menon-Sen
2004-10-15 19:08:26 +02:00
when = "UNKNOWN";
Force strings passed to and from plperl to be in UTF8 encoding. String are converted to UTF8 on the way into perl and to the database encoding on the way back. This avoids a number of observed anomalies, and ensures Perl a consistent view of the world. Some minor code cleanups are also accomplished. Alex Hunsaker, reviewed by Andy Colson.
2011-02-06 23:29:26 +01:00
hv_store_string(hv, "when", cstr2sv(when));
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
if (TRIGGER_FIRED_FOR_ROW(tdata->tg_event))
I have attached 5 patches (split up for ease of review) to plperl.c. 1. Two minor cleanups: - We don't need to call hv_exists+hv_fetch; we should just check the return value of hv_fetch. - newSVpv("undef",0) is the string "undef", not a real undef. 2. This should fix the bug Andrew Dunstan described in a recent -hackers post. It replaces three bogus "eval_pv(key, 0)" calls with newSVpv, and eliminates another redundant hv_exists+hv_fetch pair. 3. plperl_build_tuple_argument builds up a string of Perl code to create a hash representing the tuple. This patch creates the hash directly. 4. Another minor cleanup: replace a couple of av_store()s with av_push. 5. Analogous to #3 for plperl_trigger_build_args. This patch removes the static sv_add_tuple_value function, which does much the same as two other utility functions defined later, and merges the functionality into plperl_hash_from_tuple. I have tested the patches to the best of my limited ability, but I would appreciate it very much if someone else could review and test them too. (Thanks to Andrew and David Fetter for their help with some testing.) Abhijit Menon-Sen
2004-10-15 19:08:26 +02:00
level = "ROW";
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
else if (TRIGGER_FIRED_FOR_STATEMENT(tdata->tg_event))
I have attached 5 patches (split up for ease of review) to plperl.c. 1. Two minor cleanups: - We don't need to call hv_exists+hv_fetch; we should just check the return value of hv_fetch. - newSVpv("undef",0) is the string "undef", not a real undef. 2. This should fix the bug Andrew Dunstan described in a recent -hackers post. It replaces three bogus "eval_pv(key, 0)" calls with newSVpv, and eliminates another redundant hv_exists+hv_fetch pair. 3. plperl_build_tuple_argument builds up a string of Perl code to create a hash representing the tuple. This patch creates the hash directly. 4. Another minor cleanup: replace a couple of av_store()s with av_push. 5. Analogous to #3 for plperl_trigger_build_args. This patch removes the static sv_add_tuple_value function, which does much the same as two other utility functions defined later, and merges the functionality into plperl_hash_from_tuple. I have tested the patches to the best of my limited ability, but I would appreciate it very much if someone else could review and test them too. (Thanks to Andrew and David Fetter for their help with some testing.) Abhijit Menon-Sen
2004-10-15 19:08:26 +02:00
level = "STATEMENT";
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
else
I have attached 5 patches (split up for ease of review) to plperl.c. 1. Two minor cleanups: - We don't need to call hv_exists+hv_fetch; we should just check the return value of hv_fetch. - newSVpv("undef",0) is the string "undef", not a real undef. 2. This should fix the bug Andrew Dunstan described in a recent -hackers post. It replaces three bogus "eval_pv(key, 0)" calls with newSVpv, and eliminates another redundant hv_exists+hv_fetch pair. 3. plperl_build_tuple_argument builds up a string of Perl code to create a hash representing the tuple. This patch creates the hash directly. 4. Another minor cleanup: replace a couple of av_store()s with av_push. 5. Analogous to #3 for plperl_trigger_build_args. This patch removes the static sv_add_tuple_value function, which does much the same as two other utility functions defined later, and merges the functionality into plperl_hash_from_tuple. I have tested the patches to the best of my limited ability, but I would appreciate it very much if someone else could review and test them too. (Thanks to Andrew and David Fetter for their help with some testing.) Abhijit Menon-Sen
2004-10-15 19:08:26 +02:00
level = "UNKNOWN";
Force strings passed to and from plperl to be in UTF8 encoding. String are converted to UTF8 on the way into perl and to the database encoding on the way back. This avoids a number of observed anomalies, and ensures Perl a consistent view of the world. Some minor code cleanups are also accomplished. Alex Hunsaker, reviewed by Andy Colson.
2011-02-06 23:29:26 +01:00
hv_store_string(hv, "level", cstr2sv(level));
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
Further plperl cleanup: be more paranoid about checking the type of data returned from Perl. Consolidate multiple bits of code to convert a Perl hash to a tuple, and drive the conversion off the keys present in the hash rather than the tuple column names, so we detect error if the hash contains keys it shouldn't. (This means keys not in the hash will silently default to NULL, which seems ok to me.) Fix a bunch of reference-count leaks too.
2004-11-23 01:21:24 +01:00
return newRV_noinc((SV *) hv);
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
}
PL/Perl: Add event trigger support From: Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2013-12-11 14:11:59 +01:00
/* Set up the arguments for an event trigger call. */
static SV *
plperl_event_trigger_build_args(FunctionCallInfo fcinfo)
{
PL/Perl portability fix: avoid including XSUB.h in plperl.c. In Perl builds that define PERL_IMPLICIT_SYS, XSUB.h defines macros that replace a whole lot of basic libc functions with Perl functions. We can't tolerate that in plperl.c; it breaks at least PG_TRY and probably other stuff. The core idea of this patch is to include XSUB.h only in the .xs files where it's really needed, and to move any code broken by PERL_IMPLICIT_SYS out of the .xs files and into plperl.c. The reason this hasn't been a problem before is that our build techniques did not result in PERL_IMPLICIT_SYS appearing as a #define in PL/Perl, even on some platforms where Perl thinks it is defined. That's about to change in order to fix a nasty portability issue, so we need this work to make the code safe for that. Rather unaccountably, the Perl people chose XSUB.h as the place to provide the versions of the aTHX/aTHX_ macros that are needed by code that's not explicitly aware of the MULTIPLICITY API conventions. Hence, just removing XSUB.h from plperl.c fails miserably. But we can work around that by defining PERL_NO_GET_CONTEXT (which would make the relevant stanza of XSUB.h a no-op anyway). As explained in perlguts.pod, that means we need to add a "dTHX" macro call in every C function that calls a Perl API function. In most of them we just add this at the top; but since the macro fetches the current Perl interpreter pointer, more care is needed in functions that switch the active interpreter. Lack of the macro is easily recognized since it results in bleats about "my_perl" not being defined. (A nice side benefit of this is that it significantly reduces the number of fetches of the current interpreter pointer. On my machine, plperl.so gets more than 10% smaller, and there's probably some performance win too. We could reduce the number of fetches still more by decorating the code with pTHX_/aTHX_ macros to pass the interpreter pointer around, as explained by perlguts.pod; but that's a task for another day.) Formatting note: pgindent seems happy to treat "dTHX;" as a declaration so long as it's the first thing after the left brace, as we'd already observed with respect to the similar macro "dSP;". If you try to put it later in a set of declarations, pgindent puts ugly extra space around it. Having removed XSUB.h from plperl.c, we need only move the support functions for spi_return_next and util_elog (both of which use PG_TRY) out of the .xs files and into plperl.c. This seems sufficient to avoid the known problems caused by PERL_IMPLICIT_SYS, although we could move more code if additional issues emerge. This will need to be back-patched, but first let's see what the buildfarm makes of it. Patch by me, with some help from Ashutosh Sharma Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
2017-07-28 18:25:43 +02:00
dTHX;
PL/Perl: Add event trigger support From: Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2013-12-11 14:11:59 +01:00
EventTriggerData *tdata;
HV *hv;
hv = newHV();
tdata = (EventTriggerData *) fcinfo->context;
hv_store_string(hv, "event", cstr2sv(tdata->event));
Represent command completion tags as structs The backend was using strings to represent command tags and doing string comparisons in multiple places, but that's slow and unhelpful. Create a new command list with a supporting structure to use instead; this is stored in a tag-list-file that can be tailored to specific purposes with a caller-definable C macro, similar to what we do for WAL resource managers. The first first such uses are a new CommandTag enum and a CommandTagBehavior struct. Replace numerous occurrences of char *completionTag with a QueryCompletion struct so that the code no longer stores information about completed queries in a cstring. Only at the last moment, in EndCommand(), does this get converted to a string. EventTriggerCacheItem no longer holds an array of palloc’d tag strings in sorted order, but rather just a Bitmapset over the CommandTags. Author: Mark Dilger, with unsolicited help from Álvaro Herrera Reviewed-by: John Naylor, Tom Lane Discussion: https://postgr.es/m/981A9DB4-3F0C-4DA5-88AD-CB9CFF4D6CAD@enterprisedb.com
2020-03-02 22:19:51 +01:00
hv_store_string(hv, "tag", cstr2sv(GetCommandTagName(tdata->tag)));
PL/Perl: Add event trigger support From: Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2013-12-11 14:11:59 +01:00
return newRV_noinc((SV *) hv);
}
Use heap_modify_tuple not SPI_modifytuple in pl/perl triggers. The code here would need some change anyway given planned change in SPI_modifytuple semantics, since this executes after we've exited the SPI environment. But really it's better to just use heap_modify_tuple. The code's actually shorter this way, and this avoids depending on some rather indirect reasoning about why the temporary arrays can't be overrun. (I think the old code is safe, as long as Perl hashes can't contain duplicate keys; but with this way we don't need that assumption, only the assumption that SPI_fnumber doesn't return an out-of-range attnum.) While at it, normalize use of SPI_fnumber: make error messages distinguish no-such-column from can't-set-system-column, and remove test for deleted column which is going to migrate into SPI_fnumber.
2016-11-08 17:35:01 +01:00
/* Construct the modified new tuple to be returned from a trigger. */
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
static HeapTuple
Further plperl cleanup: be more paranoid about checking the type of data returned from Perl. Consolidate multiple bits of code to convert a Perl hash to a tuple, and drive the conversion off the keys present in the hash rather than the tuple column names, so we detect error if the hash contains keys it shouldn't. (This means keys not in the hash will silently default to NULL, which seems ok to me.) Fix a bunch of reference-count leaks too.
2004-11-23 01:21:24 +01:00
plperl_modify_tuple(HV *hvTD, TriggerData *tdata, HeapTuple otup)
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
{
PL/Perl portability fix: avoid including XSUB.h in plperl.c. In Perl builds that define PERL_IMPLICIT_SYS, XSUB.h defines macros that replace a whole lot of basic libc functions with Perl functions. We can't tolerate that in plperl.c; it breaks at least PG_TRY and probably other stuff. The core idea of this patch is to include XSUB.h only in the .xs files where it's really needed, and to move any code broken by PERL_IMPLICIT_SYS out of the .xs files and into plperl.c. The reason this hasn't been a problem before is that our build techniques did not result in PERL_IMPLICIT_SYS appearing as a #define in PL/Perl, even on some platforms where Perl thinks it is defined. That's about to change in order to fix a nasty portability issue, so we need this work to make the code safe for that. Rather unaccountably, the Perl people chose XSUB.h as the place to provide the versions of the aTHX/aTHX_ macros that are needed by code that's not explicitly aware of the MULTIPLICITY API conventions. Hence, just removing XSUB.h from plperl.c fails miserably. But we can work around that by defining PERL_NO_GET_CONTEXT (which would make the relevant stanza of XSUB.h a no-op anyway). As explained in perlguts.pod, that means we need to add a "dTHX" macro call in every C function that calls a Perl API function. In most of them we just add this at the top; but since the macro fetches the current Perl interpreter pointer, more care is needed in functions that switch the active interpreter. Lack of the macro is easily recognized since it results in bleats about "my_perl" not being defined. (A nice side benefit of this is that it significantly reduces the number of fetches of the current interpreter pointer. On my machine, plperl.so gets more than 10% smaller, and there's probably some performance win too. We could reduce the number of fetches still more by decorating the code with pTHX_/aTHX_ macros to pass the interpreter pointer around, as explained by perlguts.pod; but that's a task for another day.) Formatting note: pgindent seems happy to treat "dTHX;" as a declaration so long as it's the first thing after the left brace, as we'd already observed with respect to the similar macro "dSP;". If you try to put it later in a set of declarations, pgindent puts ugly extra space around it. Having removed XSUB.h from plperl.c, we need only move the support functions for spi_return_next and util_elog (both of which use PG_TRY) out of the .xs files and into plperl.c. This seems sufficient to avoid the known problems caused by PERL_IMPLICIT_SYS, although we could move more code if additional issues emerge. This will need to be back-patched, but first let's see what the buildfarm makes of it. Patch by me, with some help from Ashutosh Sharma Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
2017-07-28 18:25:43 +02:00
dTHX;
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
SV **svp;
HV *hvNew;
Force strings passed to and from plperl to be in UTF8 encoding. String are converted to UTF8 on the way into perl and to the database encoding on the way back. This avoids a number of observed anomalies, and ensures Perl a consistent view of the world. Some minor code cleanups are also accomplished. Alex Hunsaker, reviewed by Andy Colson.
2011-02-06 23:29:26 +01:00
HE *he;
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
HeapTuple rtup;
TupleDesc tupdesc;
Use heap_modify_tuple not SPI_modifytuple in pl/perl triggers. The code here would need some change anyway given planned change in SPI_modifytuple semantics, since this executes after we've exited the SPI environment. But really it's better to just use heap_modify_tuple. The code's actually shorter this way, and this avoids depending on some rather indirect reasoning about why the temporary arrays can't be overrun. (I think the old code is safe, as long as Perl hashes can't contain duplicate keys; but with this way we don't need that assumption, only the assumption that SPI_fnumber doesn't return an out-of-range attnum.) While at it, normalize use of SPI_fnumber: make error messages distinguish no-such-column from can't-set-system-column, and remove test for deleted column which is going to migrate into SPI_fnumber.
2016-11-08 17:35:01 +01:00
int natts;
Datum *modvalues;
bool *modnulls;
bool *modrepls;
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
Adjust plperl to ensure that all strings and hash keys passed to Perl are marked as UTF8 when the database encoding is UTF8. This should avoid inconsistencies like that exhibited in bug #2683 from Vitali Stupin.
2006-10-15 20:56:39 +02:00
svp = hv_fetch_string(hvTD, "new");
Further plperl cleanup: be more paranoid about checking the type of data returned from Perl. Consolidate multiple bits of code to convert a Perl hash to a tuple, and drive the conversion off the keys present in the hash rather than the tuple column names, so we detect error if the hash contains keys it shouldn't. (This means keys not in the hash will silently default to NULL, which seems ok to me.) Fix a bunch of reference-count leaks too.
2004-11-23 01:21:24 +01:00
if (!svp)
Update plperl to use ereport() not elog() for user-facing messages, so that they will be translatable. Give messages some semblance of conformance to the style guide.
2004-11-29 21:11:06 +01:00
ereport(ERROR,
(errcode(ERRCODE_UNDEFINED_COLUMN),
errmsg("$_TD->{new} does not exist")));
Use SvROK(sv) rather than directly checking SvTYPE(sv) == SVt_RV in plperl. The latter is considered unwarranted chumminess with the implementation, and can lead to crashes with recent Perl versions. Report and fix by Tim Bunce. Back-patch to all versions containing the questionable coding pattern.
2010-03-09 23:34:38 +01:00
if (!SvOK(*svp) || !SvROK(*svp) || SvTYPE(SvRV(*svp)) != SVt_PVHV)
Update plperl to use ereport() not elog() for user-facing messages, so that they will be translatable. Give messages some semblance of conformance to the style guide.
2004-11-29 21:11:06 +01:00
ereport(ERROR,
(errcode(ERRCODE_DATATYPE_MISMATCH),
errmsg("$_TD->{new} is not a hash reference")));
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
hvNew = (HV *) SvRV(*svp);
Use heap_modify_tuple not SPI_modifytuple in pl/perl triggers. The code here would need some change anyway given planned change in SPI_modifytuple semantics, since this executes after we've exited the SPI environment. But really it's better to just use heap_modify_tuple. The code's actually shorter this way, and this avoids depending on some rather indirect reasoning about why the temporary arrays can't be overrun. (I think the old code is safe, as long as Perl hashes can't contain duplicate keys; but with this way we don't need that assumption, only the assumption that SPI_fnumber doesn't return an out-of-range attnum.) While at it, normalize use of SPI_fnumber: make error messages distinguish no-such-column from can't-set-system-column, and remove test for deleted column which is going to migrate into SPI_fnumber.
2016-11-08 17:35:01 +01:00
tupdesc = tdata->tg_relation->rd_att;
natts = tupdesc->natts;
modvalues = (Datum *) palloc0(natts * sizeof(Datum));
modnulls = (bool *) palloc0(natts * sizeof(bool));
modrepls = (bool *) palloc0(natts * sizeof(bool));
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
Further plperl cleanup: be more paranoid about checking the type of data returned from Perl. Consolidate multiple bits of code to convert a Perl hash to a tuple, and drive the conversion off the keys present in the hash rather than the tuple column names, so we detect error if the hash contains keys it shouldn't. (This means keys not in the hash will silently default to NULL, which seems ok to me.) Fix a bunch of reference-count leaks too.
2004-11-23 01:21:24 +01:00
hv_iterinit(hvNew);
Force strings passed to and from plperl to be in UTF8 encoding. String are converted to UTF8 on the way into perl and to the database encoding on the way back. This avoids a number of observed anomalies, and ensures Perl a consistent view of the world. Some minor code cleanups are also accomplished. Alex Hunsaker, reviewed by Andy Colson.
2011-02-06 23:29:26 +01:00
while ((he = hv_iternext(hvNew)))
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
{
pgindent run on plperl.c
2011-02-17 20:40:13 +01:00
char *key = hek2cstr(he);
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
SV *val = HeVAL(he);
Force strings passed to and from plperl to be in UTF8 encoding. String are converted to UTF8 on the way into perl and to the database encoding on the way back. This avoids a number of observed anomalies, and ensures Perl a consistent view of the world. Some minor code cleanups are also accomplished. Alex Hunsaker, reviewed by Andy Colson.
2011-02-06 23:29:26 +01:00
int attn = SPI_fnumber(tupdesc, key);
Change tupledesc->attrs[n] to TupleDescAttr(tupledesc, n). This is a mechanical change in preparation for a later commit that will change the layout of TupleDesc. Introducing a macro to abstract the details of where attributes are stored will allow us to change that in separate step and revise it in future. Author: Thomas Munro, editorialized by Andres Freund Reviewed-By: Andres Freund Discussion: https://postgr.es/m/CAEepm=0ZtQ-SpsgCyzzYpsXS6e=kZWqk3g5Ygn3MDV7A8dabUA@mail.gmail.com
2017-08-20 20:19:07 +02:00
Form_pg_attribute attr = TupleDescAttr(tupdesc, attn - 1);
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
Use heap_modify_tuple not SPI_modifytuple in pl/perl triggers. The code here would need some change anyway given planned change in SPI_modifytuple semantics, since this executes after we've exited the SPI environment. But really it's better to just use heap_modify_tuple. The code's actually shorter this way, and this avoids depending on some rather indirect reasoning about why the temporary arrays can't be overrun. (I think the old code is safe, as long as Perl hashes can't contain duplicate keys; but with this way we don't need that assumption, only the assumption that SPI_fnumber doesn't return an out-of-range attnum.) While at it, normalize use of SPI_fnumber: make error messages distinguish no-such-column from can't-set-system-column, and remove test for deleted column which is going to migrate into SPI_fnumber.
2016-11-08 17:35:01 +01:00
if (attn == SPI_ERROR_NOATTRIBUTE)
Update plperl to use ereport() not elog() for user-facing messages, so that they will be translatable. Give messages some semblance of conformance to the style guide.
2004-11-29 21:11:06 +01:00
ereport(ERROR,
(errcode(ERRCODE_UNDEFINED_COLUMN),
errmsg("Perl hash contains nonexistent column \"%s\"",
key)));
Use heap_modify_tuple not SPI_modifytuple in pl/perl triggers. The code here would need some change anyway given planned change in SPI_modifytuple semantics, since this executes after we've exited the SPI environment. But really it's better to just use heap_modify_tuple. The code's actually shorter this way, and this avoids depending on some rather indirect reasoning about why the temporary arrays can't be overrun. (I think the old code is safe, as long as Perl hashes can't contain duplicate keys; but with this way we don't need that assumption, only the assumption that SPI_fnumber doesn't return an out-of-range attnum.) While at it, normalize use of SPI_fnumber: make error messages distinguish no-such-column from can't-set-system-column, and remove test for deleted column which is going to migrate into SPI_fnumber.
2016-11-08 17:35:01 +01:00
if (attn <= 0)
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("cannot set system attribute \"%s\"",
key)));
Generated columns This is an SQL-standard feature that allows creating columns that are computed from expressions rather than assigned, similar to a view or materialized view but on a column basis. This implements one kind of generated column: stored (computed on write). Another kind, virtual (computed on read), is planned for the future, and some room is left for it. Reviewed-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Pavel Stehule <pavel.stehule@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/b151f851-4019-bdb1-699e-ebab07d2f40a@2ndquadrant.com
2019-03-30 08:13:09 +01:00
if (attr->attgenerated)
ereport(ERROR,
(errcode(ERRCODE_E_R_I_E_TRIGGER_PROTOCOL_VIOLATED),
errmsg("cannot set generated column \"%s\"",
key)));
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
Use heap_modify_tuple not SPI_modifytuple in pl/perl triggers. The code here would need some change anyway given planned change in SPI_modifytuple semantics, since this executes after we've exited the SPI environment. But really it's better to just use heap_modify_tuple. The code's actually shorter this way, and this avoids depending on some rather indirect reasoning about why the temporary arrays can't be overrun. (I think the old code is safe, as long as Perl hashes can't contain duplicate keys; but with this way we don't need that assumption, only the assumption that SPI_fnumber doesn't return an out-of-range attnum.) While at it, normalize use of SPI_fnumber: make error messages distinguish no-such-column from can't-set-system-column, and remove test for deleted column which is going to migrate into SPI_fnumber.
2016-11-08 17:35:01 +01:00
modvalues[attn - 1] = plperl_sv_to_datum(val,
Change tupledesc->attrs[n] to TupleDescAttr(tupledesc, n). This is a mechanical change in preparation for a later commit that will change the layout of TupleDesc. Introducing a macro to abstract the details of where attributes are stored will allow us to change that in separate step and revise it in future. Author: Thomas Munro, editorialized by Andres Freund Reviewed-By: Andres Freund Discussion: https://postgr.es/m/CAEepm=0ZtQ-SpsgCyzzYpsXS6e=kZWqk3g5Ygn3MDV7A8dabUA@mail.gmail.com
2017-08-20 20:19:07 +02:00
attr->atttypid,
attr->atttypmod,
Use heap_modify_tuple not SPI_modifytuple in pl/perl triggers. The code here would need some change anyway given planned change in SPI_modifytuple semantics, since this executes after we've exited the SPI environment. But really it's better to just use heap_modify_tuple. The code's actually shorter this way, and this avoids depending on some rather indirect reasoning about why the temporary arrays can't be overrun. (I think the old code is safe, as long as Perl hashes can't contain duplicate keys; but with this way we don't need that assumption, only the assumption that SPI_fnumber doesn't return an out-of-range attnum.) While at it, normalize use of SPI_fnumber: make error messages distinguish no-such-column from can't-set-system-column, and remove test for deleted column which is going to migrate into SPI_fnumber.
2016-11-08 17:35:01 +01:00
NULL,
NULL,
InvalidOid,
&modnulls[attn - 1]);
modrepls[attn - 1] = true;
Force strings passed to and from plperl to be in UTF8 encoding. String are converted to UTF8 on the way into perl and to the database encoding on the way back. This avoids a number of observed anomalies, and ensures Perl a consistent view of the world. Some minor code cleanups are also accomplished. Alex Hunsaker, reviewed by Andy Colson.
2011-02-06 23:29:26 +01:00
pfree(key);
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
}
Further plperl cleanup: be more paranoid about checking the type of data returned from Perl. Consolidate multiple bits of code to convert a Perl hash to a tuple, and drive the conversion off the keys present in the hash rather than the tuple column names, so we detect error if the hash contains keys it shouldn't. (This means keys not in the hash will silently default to NULL, which seems ok to me.) Fix a bunch of reference-count leaks too.
2004-11-23 01:21:24 +01:00
hv_iterinit(hvNew);
Use heap_modify_tuple not SPI_modifytuple in pl/perl triggers. The code here would need some change anyway given planned change in SPI_modifytuple semantics, since this executes after we've exited the SPI environment. But really it's better to just use heap_modify_tuple. The code's actually shorter this way, and this avoids depending on some rather indirect reasoning about why the temporary arrays can't be overrun. (I think the old code is safe, as long as Perl hashes can't contain duplicate keys; but with this way we don't need that assumption, only the assumption that SPI_fnumber doesn't return an out-of-range attnum.) While at it, normalize use of SPI_fnumber: make error messages distinguish no-such-column from can't-set-system-column, and remove test for deleted column which is going to migrate into SPI_fnumber.
2016-11-08 17:35:01 +01:00
rtup = heap_modify_tuple(otup, tupdesc, modvalues, modnulls, modrepls);
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
pfree(modvalues);
pfree(modnulls);
Use heap_modify_tuple not SPI_modifytuple in pl/perl triggers. The code here would need some change anyway given planned change in SPI_modifytuple semantics, since this executes after we've exited the SPI environment. But really it's better to just use heap_modify_tuple. The code's actually shorter this way, and this avoids depending on some rather indirect reasoning about why the temporary arrays can't be overrun. (I think the old code is safe, as long as Perl hashes can't contain duplicate keys; but with this way we don't need that assumption, only the assumption that SPI_fnumber doesn't return an out-of-range attnum.) While at it, normalize use of SPI_fnumber: make error messages distinguish no-such-column from can't-set-system-column, and remove test for deleted column which is going to migrate into SPI_fnumber.
2016-11-08 17:35:01 +01:00
pfree(modrepls);
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
return rtup;
}
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
At 2005-05-21 20:18:50 +0530, ams@oryx.com wrote: > > > The second issue is where plperl returns a large result set. I have attached the following seven patches to address this problem: 1. Trivial. Replaces some errant spaces with tabs. 2. Trivial. Fixes the spelling of Jan's name, and gets rid of many inane, useless, annoying, and often misleading comments. Here's a sample: "plperl_init_all() - Initialize all". (I have tried to add some useful comments here and there, and will continue to do so now and again.) 3. Trivial. Splits up some long lines. 4. Converts SRFs in PL/Perl to use a Tuplestore and SFRM_Materialize to return the result set, based on the PL/PgSQL model. There are two major consequences: result sets will spill to disk when they can no longer fit in work_mem; and "select foo_srf()" no longer works. (I didn't lose sleep over the latter, since that form is not valid in PL/PgSQL, and it's not documented in PL/Perl.) 5. Trivial, but important. Fixes use of "undef" instead of undef. This would cause empty functions to fail in bizarre ways. I suspect that there's still another (old) bug here. I'll investigate further. 6. Moves the majority of (4) out into a new plperl_return_next() function, to make it possible to expose the functionality to Perl; cleans up some of the code besides. 7. Add an spi_return_next function for use in Perl code. If you want to apply the patches and try them out, 8-composite.diff is what you should use. (Note: my patches depend upon Andrew's use-strict and %_SHARED patches being applied.) Here's something to try: create or replace function foo() returns setof record as $$ $i = 0; for ("World", "PostgreSQL", "PL/Perl") { spi_return_next({f1=>++$i, f2=>'Hello', f3=>$_}); } return; $$ language plperl; select * from foo() as (f1 integer, f2 text, f3 text); (Many thanks to Andrews Dunstan and Supernews for their help.) Abhijit Menon-Sen
2005-06-04 22:33:06 +02:00
Add a validator function for plperl. Andrew Dunstan
2005-06-22 18:45:51 +02:00
/*
Add support for anonymous code blocks (DO blocks) to PL/Perl. Joshua Tolley, reviewed by Brendan Jurd and Tim Bunce
2009-11-29 04:02:27 +01:00
* There are three externally visible pieces to plperl: plperl_call_handler,
* plperl_inline_handler, and plperl_validator.
*/
/*
* The call handler is called to run normal functions (including trigger
* functions) that are defined in pg_proc.
Add a validator function for plperl. Andrew Dunstan
2005-06-22 18:45:51 +02:00
*/
Revise handling of oldstyle/newstyle functions per recent discussions in pghackers list. Support for oldstyle internal functions is gone (no longer needed, since conversion is complete) and pg_language entry 'internal' now implies newstyle call convention. pg_language entry 'newC' is gone; both old and newstyle dynamically loaded C functions are now called language 'C'. A newstyle function must be identified by an associated info routine. See src/backend/utils/fmgr/README.
2000-11-20 21:36:57 +01:00
PG_FUNCTION_INFO_V1(plperl_call_handler);
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
Datum
First round of changes for new fmgr interface. fmgr itself and the key call sites are changed, but most called functions are still oldstyle. An exception is that the PL managers are updated (so, for example, NULL handling now behaves as expected in plperl and plpgsql functions). NOTE initdb is forced due to added column in pg_proc.
2000-05-28 19:56:29 +02:00
plperl_call_handler(PG_FUNCTION_ARGS)
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
{
Fix some compiler warnings on older compilers Some older compilers appear to not understand the recently introduced PG_FINALLY code structure that well in some circumstances and complain about possibly uninitialized variables. So to fix, initialize the variables explicitly in the cases complained about. Discussion: https://www.postgresql.org/message-id/flat/95a822c3-728b-af0e-d7e5-71890507ae0c%402ndquadrant.com
2019-11-04 11:07:32 +01:00
Datum retval = (Datum) 0;
Volatile-ize some plperl variables that must survive into PG_CATCH blocks. This appears to be necessary to fix a failure seen on buildfarm member sittella. It shouldn't be necessary according to the letter of the C standard, because we don't change the values of these variables within the PG_TRY blocks; but somehow gcc 4.7.2 is dropping the ball. Discussion: https://postgr.es/m/17555.1485179975@sss.pgh.pa.us
2017-01-23 15:15:49 +01:00
plperl_call_data *volatile save_call_data = current_call_data;
plperl_interp_desc *volatile oldinterp = plperl_active_interp;
Keep plperl's current_call_data record on the stack, instead of palloc'ing. This at least saves some palloc overhead, and should furthermore reduce the risk of anything going wrong, eg somebody resetting the context the current_call_data record was in.
2012-09-13 19:44:20 +02:00
plperl_call_data this_call_data;
/* Initialize current-call status record */
MemSet(&this_call_data, 0, sizeof(this_call_data));
this_call_data.fcinfo = fcinfo;
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
Redesign query-snapshot timing so that volatile functions in READ COMMITTED mode see a fresh snapshot for each command in the function, rather than using the latest interactive command's snapshot. Also, suppress fresh snapshots as well as CommandCounterIncrement inside STABLE and IMMUTABLE functions, instead using the snapshot taken for the most closely nested regular query. (This behavior is only sane for read-only functions, so the patch also enforces that such functions contain only SELECT commands.) As per my proposal of 6-Sep-2004; I note that I floated essentially the same proposal on 19-Jun-2002, but that discussion tailed off without any action. Since 8.0 seems like the right place to be taking possibly nontrivial backwards compatibility hits, let's get it done now.
2004-09-13 22:10:13 +02:00
PG_TRY();
{
Keep plperl's current_call_data record on the stack, instead of palloc'ing. This at least saves some palloc overhead, and should furthermore reduce the risk of anything going wrong, eg somebody resetting the context the current_call_data record was in.
2012-09-13 19:44:20 +02:00
current_call_data = &this_call_data;
Redesign query-snapshot timing so that volatile functions in READ COMMITTED mode see a fresh snapshot for each command in the function, rather than using the latest interactive command's snapshot. Also, suppress fresh snapshots as well as CommandCounterIncrement inside STABLE and IMMUTABLE functions, instead using the snapshot taken for the most closely nested regular query. (This behavior is only sane for read-only functions, so the patch also enforces that such functions contain only SELECT commands.) As per my proposal of 6-Sep-2004; I note that I floated essentially the same proposal on 19-Jun-2002, but that discussion tailed off without any action. Since 8.0 seems like the right place to be taking possibly nontrivial backwards compatibility hits, let's get it done now.
2004-09-13 22:10:13 +02:00
if (CALLED_AS_TRIGGER(fcinfo))
Fix incorrect uses of Datum conversion macros Since these macros just cast whatever you give them to the designated output type, and many normal uses also cast the output type further, a number of incorrect uses go undiscovered. The fixes in this patch have been discovered by changing these macros to inline functions, which is the subject of a future patch. Reviewed-by: Aleksander Alekseev <aleksander@timescale.com> Discussion: https://www.postgresql.org/message-id/flat/8528fb7e-0aa2-6b54-85fb-0c0886dbd6ed%40enterprisedb.com
2022-08-28 10:47:10 +02:00
retval = plperl_trigger_handler(fcinfo);
PL/Perl: Add event trigger support From: Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2013-12-11 14:11:59 +01:00
else if (CALLED_AS_EVENT_TRIGGER(fcinfo))
{
plperl_event_trigger_handler(fcinfo);
retval = (Datum) 0;
}
Redesign query-snapshot timing so that volatile functions in READ COMMITTED mode see a fresh snapshot for each command in the function, rather than using the latest interactive command's snapshot. Also, suppress fresh snapshots as well as CommandCounterIncrement inside STABLE and IMMUTABLE functions, instead using the snapshot taken for the most closely nested regular query. (This behavior is only sane for read-only functions, so the patch also enforces that such functions contain only SELECT commands.) As per my proposal of 6-Sep-2004; I note that I floated essentially the same proposal on 19-Jun-2002, but that discussion tailed off without any action. Since 8.0 seems like the right place to be taking possibly nontrivial backwards compatibility hits, let's get it done now.
2004-09-13 22:10:13 +02:00
else
retval = plperl_func_handler(fcinfo);
}
PG_FINALLY This gives an alternative way of catching exceptions, for the common case where the cleanup code is the same in the error and non-error cases. So instead of PG_TRY(); { ... code that might throw ereport(ERROR) ... } PG_CATCH(); { cleanup(); PG_RE_THROW(); } PG_END_TRY(); cleanup(); one can write PG_TRY(); { ... code that might throw ereport(ERROR) ... } PG_FINALLY(); { cleanup(); } PG_END_TRY(); Discussion: https://www.postgresql.org/message-id/flat/95a822c3-728b-af0e-d7e5-71890507ae0c%402ndquadrant.com
2019-11-01 11:09:52 +01:00
PG_FINALLY();
Redesign query-snapshot timing so that volatile functions in READ COMMITTED mode see a fresh snapshot for each command in the function, rather than using the latest interactive command's snapshot. Also, suppress fresh snapshots as well as CommandCounterIncrement inside STABLE and IMMUTABLE functions, instead using the snapshot taken for the most closely nested regular query. (This behavior is only sane for read-only functions, so the patch also enforces that such functions contain only SELECT commands.) As per my proposal of 6-Sep-2004; I note that I floated essentially the same proposal on 19-Jun-2002, but that discussion tailed off without any action. Since 8.0 seems like the right place to be taking possibly nontrivial backwards compatibility hits, let's get it done now.
2004-09-13 22:10:13 +02:00
{
Per a bug report from Theo Schlossnagle, plperl_return_next() leaks memory in the executor's per-query memory context. It also inefficient: it invokes get_call_result_type() and TupleDescGetAttInMetadata() for every call to return_next, rather than invoking them once (per PL/Perl function call) and memoizing the result. This patch makes the following changes: - refactor the code to include all the "per PL/Perl function call" data inside a single struct, "current_call_data". This means we don't need to save and restore N pointers for every recursive call into PL/Perl, we can just save and restore one. - lookup the return type metadata needed by plperl_return_next() once, and then stash it in "current_call_data", so as to avoid doing the lookup for every call to return_next. - create a temporary memory context in which to evaluate the return type's input functions. This memory context is reset for each call to return_next. The patch appears to fix the memory leak, and substantially reduces the overhead imposed by return_next.
2006-01-28 04:28:15 +01:00
current_call_data = save_call_data;
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
activate_interpreter(oldinterp);
Improve memory management for PL/Perl functions. Unlike PL/Tcl, PL/Perl at least made an attempt to clean up after itself when a function gets redefined. But it was still using TopMemoryContext for the fn_mcxt of argument/result I/O functions, resulting in the potential for memory leaks depending on what those functions did, and the retail alloc/free logic was pretty bulky as well. Fix things to use a per-function memory context like the other PLs now do. Tweak a couple of places where things were being done in a not-very-safe order (on the principle that a memory leak is better than leaving global state inconsistent after an error). Also make some minor cosmetic adjustments, mostly in field names, to make the code look similar to the way PL/Tcl does now wherever it's essentially the same logic. Michael Paquier and Tom Lane Discussion: <CAB7nPqSOyAsHC6jL24J1B+oK3p=yyNoFU0Vs_B6fd2kdd5g5WQ@mail.gmail.com>
2016-09-01 01:54:58 +02:00
if (this_call_data.prodesc)
decrement_prodesc_refcount(this_call_data.prodesc);
Redesign query-snapshot timing so that volatile functions in READ COMMITTED mode see a fresh snapshot for each command in the function, rather than using the latest interactive command's snapshot. Also, suppress fresh snapshots as well as CommandCounterIncrement inside STABLE and IMMUTABLE functions, instead using the snapshot taken for the most closely nested regular query. (This behavior is only sane for read-only functions, so the patch also enforces that such functions contain only SELECT commands.) As per my proposal of 6-Sep-2004; I note that I floated essentially the same proposal on 19-Jun-2002, but that discussion tailed off without any action. Since 8.0 seems like the right place to be taking possibly nontrivial backwards compatibility hits, let's get it done now.
2004-09-13 22:10:13 +02:00
}
PG_END_TRY();
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
return retval;
}
Add a validator function for plperl. Andrew Dunstan
2005-06-22 18:45:51 +02:00
/*
Add support for anonymous code blocks (DO blocks) to PL/Perl. Joshua Tolley, reviewed by Brendan Jurd and Tim Bunce
2009-11-29 04:02:27 +01:00
* The inline handler runs anonymous code blocks (DO blocks).
*/
PG_FUNCTION_INFO_V1(plperl_inline_handler);
Datum
plperl_inline_handler(PG_FUNCTION_ARGS)
{
Change function call information to be variable length. Before this change FunctionCallInfoData, the struct arguments etc for V1 function calls are stored in, always had space for FUNC_MAX_ARGS/100 arguments, storing datums and their nullness in two arrays. For nearly every function call 100 arguments is far more than needed, therefore wasting memory. Arg and argnull being two separate arrays also guarantees that to access a single argument, two cachelines have to be touched. Change the layout so there's a single variable-length array with pairs of value / isnull. That drastically reduces memory consumption for most function calls (on x86-64 a two argument function now uses 64bytes, previously 936 bytes), and makes it very likely that argument value and its nullness are on the same cacheline. Arguments are stored in a new NullableDatum struct, which, due to padding, needs more memory per argument than before. But as usually far fewer arguments are stored, and individual arguments are cheaper to access, that's still a clear win. It's likely that there's other places where conversion to NullableDatum arrays would make sense, e.g. TupleTableSlots, but that's for another commit. Because the function call information is now variable-length allocations have to take the number of arguments into account. For heap allocations that can be done with SizeForFunctionCallInfoData(), for on-stack allocations there's a new LOCAL_FCINFO(name, nargs) macro that helps to allocate an appropriately sized and aligned variable. Some places with stack allocation function call information don't know the number of arguments at compile time, and currently variably sized stack allocations aren't allowed in postgres. Therefore allow for FUNC_MAX_ARGS space in these cases. They're not that common, so for now that seems acceptable. Because of the need to allocate FunctionCallInfo of the appropriate size, older extensions may need to update their code. To avoid subtle breakages, the FunctionCallInfoData struct has been renamed to FunctionCallInfoBaseData. Most code only references FunctionCallInfo, so that shouldn't cause much collateral damage. This change is also a prerequisite for more efficient expression JIT compilation (by allocating the function call information on the stack, allowing LLVM to optimize it away); previously the size of the call information caused problems inside LLVM's optimizer. Author: Andres Freund Reviewed-By: Tom Lane Discussion: https://postgr.es/m/20180605172952.x34m5uz6ju6enaem@alap3.anarazel.de
2019-01-26 23:17:52 +01:00
LOCAL_FCINFO(fake_fcinfo, 0);
Add support for anonymous code blocks (DO blocks) to PL/Perl. Joshua Tolley, reviewed by Brendan Jurd and Tim Bunce
2009-11-29 04:02:27 +01:00
InlineCodeBlock *codeblock = (InlineCodeBlock *) PG_GETARG_POINTER(0);
FmgrInfo flinfo;
plperl_proc_desc desc;
Volatile-ize some plperl variables that must survive into PG_CATCH blocks. This appears to be necessary to fix a failure seen on buildfarm member sittella. It shouldn't be necessary according to the letter of the C standard, because we don't change the values of these variables within the PG_TRY blocks; but somehow gcc 4.7.2 is dropping the ball. Discussion: https://postgr.es/m/17555.1485179975@sss.pgh.pa.us
2017-01-23 15:15:49 +01:00
plperl_call_data *volatile save_call_data = current_call_data;
plperl_interp_desc *volatile oldinterp = plperl_active_interp;
Keep plperl's current_call_data record on the stack, instead of palloc'ing. This at least saves some palloc overhead, and should furthermore reduce the risk of anything going wrong, eg somebody resetting the context the current_call_data record was in.
2012-09-13 19:44:20 +02:00
plperl_call_data this_call_data;
Add support for anonymous code blocks (DO blocks) to PL/Perl. Joshua Tolley, reviewed by Brendan Jurd and Tim Bunce
2009-11-29 04:02:27 +01:00
ErrorContextCallback pl_error_context;
Keep plperl's current_call_data record on the stack, instead of palloc'ing. This at least saves some palloc overhead, and should furthermore reduce the risk of anything going wrong, eg somebody resetting the context the current_call_data record was in.
2012-09-13 19:44:20 +02:00
/* Initialize current-call status record */
MemSet(&this_call_data, 0, sizeof(this_call_data));
Add support for anonymous code blocks (DO blocks) to PL/Perl. Joshua Tolley, reviewed by Brendan Jurd and Tim Bunce
2009-11-29 04:02:27 +01:00
/* Set up a callback for error reporting */
pl_error_context.callback = plperl_inline_callback;
pl_error_context.previous = error_context_stack;
PL/Perl: Fix compiler warning The code was assigning a (Datum) 0 to a void pointer. That creates a warning from clang 3.4. It was probably a thinko to begin with.
2014-02-05 02:04:35 +01:00
pl_error_context.arg = NULL;
Add support for anonymous code blocks (DO blocks) to PL/Perl. Joshua Tolley, reviewed by Brendan Jurd and Tim Bunce
2009-11-29 04:02:27 +01:00
error_context_stack = &pl_error_context;
/*
* Set up a fake fcinfo and descriptor with just enough info to satisfy
* plperl_call_perl_func(). In particular note that this sets things up
* with no arguments passed, and a result type of VOID.
*/
Change function call information to be variable length. Before this change FunctionCallInfoData, the struct arguments etc for V1 function calls are stored in, always had space for FUNC_MAX_ARGS/100 arguments, storing datums and their nullness in two arrays. For nearly every function call 100 arguments is far more than needed, therefore wasting memory. Arg and argnull being two separate arrays also guarantees that to access a single argument, two cachelines have to be touched. Change the layout so there's a single variable-length array with pairs of value / isnull. That drastically reduces memory consumption for most function calls (on x86-64 a two argument function now uses 64bytes, previously 936 bytes), and makes it very likely that argument value and its nullness are on the same cacheline. Arguments are stored in a new NullableDatum struct, which, due to padding, needs more memory per argument than before. But as usually far fewer arguments are stored, and individual arguments are cheaper to access, that's still a clear win. It's likely that there's other places where conversion to NullableDatum arrays would make sense, e.g. TupleTableSlots, but that's for another commit. Because the function call information is now variable-length allocations have to take the number of arguments into account. For heap allocations that can be done with SizeForFunctionCallInfoData(), for on-stack allocations there's a new LOCAL_FCINFO(name, nargs) macro that helps to allocate an appropriately sized and aligned variable. Some places with stack allocation function call information don't know the number of arguments at compile time, and currently variably sized stack allocations aren't allowed in postgres. Therefore allow for FUNC_MAX_ARGS space in these cases. They're not that common, so for now that seems acceptable. Because of the need to allocate FunctionCallInfo of the appropriate size, older extensions may need to update their code. To avoid subtle breakages, the FunctionCallInfoData struct has been renamed to FunctionCallInfoBaseData. Most code only references FunctionCallInfo, so that shouldn't cause much collateral damage. This change is also a prerequisite for more efficient expression JIT compilation (by allocating the function call information on the stack, allowing LLVM to optimize it away); previously the size of the call information caused problems inside LLVM's optimizer. Author: Andres Freund Reviewed-By: Tom Lane Discussion: https://postgr.es/m/20180605172952.x34m5uz6ju6enaem@alap3.anarazel.de
2019-01-26 23:17:52 +01:00
MemSet(fake_fcinfo, 0, SizeForFunctionCallInfo(0));
Add support for anonymous code blocks (DO blocks) to PL/Perl. Joshua Tolley, reviewed by Brendan Jurd and Tim Bunce
2009-11-29 04:02:27 +01:00
MemSet(&flinfo, 0, sizeof(flinfo));
MemSet(&desc, 0, sizeof(desc));
Change function call information to be variable length. Before this change FunctionCallInfoData, the struct arguments etc for V1 function calls are stored in, always had space for FUNC_MAX_ARGS/100 arguments, storing datums and their nullness in two arrays. For nearly every function call 100 arguments is far more than needed, therefore wasting memory. Arg and argnull being two separate arrays also guarantees that to access a single argument, two cachelines have to be touched. Change the layout so there's a single variable-length array with pairs of value / isnull. That drastically reduces memory consumption for most function calls (on x86-64 a two argument function now uses 64bytes, previously 936 bytes), and makes it very likely that argument value and its nullness are on the same cacheline. Arguments are stored in a new NullableDatum struct, which, due to padding, needs more memory per argument than before. But as usually far fewer arguments are stored, and individual arguments are cheaper to access, that's still a clear win. It's likely that there's other places where conversion to NullableDatum arrays would make sense, e.g. TupleTableSlots, but that's for another commit. Because the function call information is now variable-length allocations have to take the number of arguments into account. For heap allocations that can be done with SizeForFunctionCallInfoData(), for on-stack allocations there's a new LOCAL_FCINFO(name, nargs) macro that helps to allocate an appropriately sized and aligned variable. Some places with stack allocation function call information don't know the number of arguments at compile time, and currently variably sized stack allocations aren't allowed in postgres. Therefore allow for FUNC_MAX_ARGS space in these cases. They're not that common, so for now that seems acceptable. Because of the need to allocate FunctionCallInfo of the appropriate size, older extensions may need to update their code. To avoid subtle breakages, the FunctionCallInfoData struct has been renamed to FunctionCallInfoBaseData. Most code only references FunctionCallInfo, so that shouldn't cause much collateral damage. This change is also a prerequisite for more efficient expression JIT compilation (by allocating the function call information on the stack, allowing LLVM to optimize it away); previously the size of the call information caused problems inside LLVM's optimizer. Author: Andres Freund Reviewed-By: Tom Lane Discussion: https://postgr.es/m/20180605172952.x34m5uz6ju6enaem@alap3.anarazel.de
2019-01-26 23:17:52 +01:00
fake_fcinfo->flinfo = &flinfo;
Add support for anonymous code blocks (DO blocks) to PL/Perl. Joshua Tolley, reviewed by Brendan Jurd and Tim Bunce
2009-11-29 04:02:27 +01:00
flinfo.fn_oid = InvalidOid;
flinfo.fn_mcxt = CurrentMemoryContext;
desc.proname = "inline_code_block";
desc.fn_readonly = false;
Add transforms feature This provides a mechanism for specifying conversions between SQL data types and procedural languages. As examples, there are transforms for hstore and ltree for PL/Perl and PL/Python. reviews by Pavel Stěhule and Andres Freund
2015-04-26 16:33:14 +02:00
desc.lang_oid = codeblock->langOid;
desc.trftypes = NIL;
Add support for anonymous code blocks (DO blocks) to PL/Perl. Joshua Tolley, reviewed by Brendan Jurd and Tim Bunce
2009-11-29 04:02:27 +01:00
desc.lanpltrusted = codeblock->langIsTrusted;
desc.fn_retistuple = false;
desc.fn_retisset = false;
desc.fn_retisarray = false;
SQL procedures This adds a new object type "procedure" that is similar to a function but does not have a return type and is invoked by the new CALL statement instead of SELECT or similar. This implementation is aligned with the SQL standard and compatible with or similar to other SQL implementations. This commit adds new commands CALL, CREATE/ALTER/DROP PROCEDURE, as well as ALTER/DROP ROUTINE that can refer to either a function or a procedure (or an aggregate function, as an extension to SQL). There is also support for procedures in various utility commands such as COMMENT and GRANT, as well as support in pg_dump and psql. Support for defining procedures is available in all the languages supplied by the core distribution. While this commit is mainly syntax sugar around existing functionality, future features will rely on having procedures as a separate object type. Reviewed-by: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
2017-11-30 14:46:13 +01:00
desc.result_oid = InvalidOid;
Add support for anonymous code blocks (DO blocks) to PL/Perl. Joshua Tolley, reviewed by Brendan Jurd and Tim Bunce
2009-11-29 04:02:27 +01:00
desc.nargs = 0;
desc.reference = NULL;
Change function call information to be variable length. Before this change FunctionCallInfoData, the struct arguments etc for V1 function calls are stored in, always had space for FUNC_MAX_ARGS/100 arguments, storing datums and their nullness in two arrays. For nearly every function call 100 arguments is far more than needed, therefore wasting memory. Arg and argnull being two separate arrays also guarantees that to access a single argument, two cachelines have to be touched. Change the layout so there's a single variable-length array with pairs of value / isnull. That drastically reduces memory consumption for most function calls (on x86-64 a two argument function now uses 64bytes, previously 936 bytes), and makes it very likely that argument value and its nullness are on the same cacheline. Arguments are stored in a new NullableDatum struct, which, due to padding, needs more memory per argument than before. But as usually far fewer arguments are stored, and individual arguments are cheaper to access, that's still a clear win. It's likely that there's other places where conversion to NullableDatum arrays would make sense, e.g. TupleTableSlots, but that's for another commit. Because the function call information is now variable-length allocations have to take the number of arguments into account. For heap allocations that can be done with SizeForFunctionCallInfoData(), for on-stack allocations there's a new LOCAL_FCINFO(name, nargs) macro that helps to allocate an appropriately sized and aligned variable. Some places with stack allocation function call information don't know the number of arguments at compile time, and currently variably sized stack allocations aren't allowed in postgres. Therefore allow for FUNC_MAX_ARGS space in these cases. They're not that common, so for now that seems acceptable. Because of the need to allocate FunctionCallInfo of the appropriate size, older extensions may need to update their code. To avoid subtle breakages, the FunctionCallInfoData struct has been renamed to FunctionCallInfoBaseData. Most code only references FunctionCallInfo, so that shouldn't cause much collateral damage. This change is also a prerequisite for more efficient expression JIT compilation (by allocating the function call information on the stack, allowing LLVM to optimize it away); previously the size of the call information caused problems inside LLVM's optimizer. Author: Andres Freund Reviewed-By: Tom Lane Discussion: https://postgr.es/m/20180605172952.x34m5uz6ju6enaem@alap3.anarazel.de
2019-01-26 23:17:52 +01:00
this_call_data.fcinfo = fake_fcinfo;
Keep plperl's current_call_data record on the stack, instead of palloc'ing. This at least saves some palloc overhead, and should furthermore reduce the risk of anything going wrong, eg somebody resetting the context the current_call_data record was in.
2012-09-13 19:44:20 +02:00
this_call_data.prodesc = &desc;
/* we do not bother with refcounting the fake prodesc */
Add support for anonymous code blocks (DO blocks) to PL/Perl. Joshua Tolley, reviewed by Brendan Jurd and Tim Bunce
2009-11-29 04:02:27 +01:00
PG_TRY();
{
SV *perlret;
Keep plperl's current_call_data record on the stack, instead of palloc'ing. This at least saves some palloc overhead, and should furthermore reduce the risk of anything going wrong, eg somebody resetting the context the current_call_data record was in.
2012-09-13 19:44:20 +02:00
current_call_data = &this_call_data;
Make plperl safe against functions that are redefined while running. validate_plperl_function() supposed that it could free an old plperl_proc_desc struct immediately upon detecting that it was stale. However, if a plperl function is called recursively, this could result in deleting the struct out from under an outer invocation, leading to misbehavior or crashes. Add a simple reference-count mechanism to ensure that such structs are freed only when the last reference goes away. Per investigation of bug #7516 from Marko Tiikkaja. I am not certain that this error explains his report, because he says he didn't have any recursive calls --- but it's hard to see how else it could have crashed right there. In any case, this definitely fixes some problems in the area. Back-patch to all active branches.
2012-09-10 02:32:54 +02:00
Transaction control in PL procedures In each of the supplied procedural languages (PL/pgSQL, PL/Perl, PL/Python, PL/Tcl), add language-specific commit and rollback functions/commands to control transactions in procedures in that language. Add similar underlying functions to SPI. Some additional cleanup so that transaction commit or abort doesn't blow away data structures still used by the procedure call. Add execution context tracking to CALL and DO statements so that transaction control commands can only be issued in top-level procedure and block calls, not function calls or other procedure or block calls. - SPI Add a new function SPI_connect_ext() that is like SPI_connect() but allows passing option flags. The only option flag right now is SPI_OPT_NONATOMIC. A nonatomic SPI connection can execute transaction control commands, otherwise it's not allowed. This is meant to be passed down from CALL and DO statements which themselves know in which context they are called. A nonatomic SPI connection uses different memory management. A normal SPI connection allocates its memory in TopTransactionContext. For nonatomic connections we use PortalContext instead. As the comment in SPI_connect_ext() (previously SPI_connect()) indicates, one could potentially use PortalContext in all cases, but it seems safest to leave the existing uses alone, because this stuff is complicated enough already. SPI also gets new functions SPI_start_transaction(), SPI_commit(), and SPI_rollback(), which can be used by PLs to implement their transaction control logic. - portalmem.c Some adjustments were made in the code that cleans up portals at transaction abort. The portal code could already handle a command *committing* a transaction and continuing (e.g., VACUUM), but it was not quite prepared for a command *aborting* a transaction and continuing. In AtAbort_Portals(), remove the code that marks an active portal as failed. As the comment there already predicted, this doesn't work if the running command wants to keep running after transaction abort. And it's actually not necessary, because pquery.c is careful to run all portal code in a PG_TRY block and explicitly runs MarkPortalFailed() if there is an exception. So the code in AtAbort_Portals() is never used anyway. In AtAbort_Portals() and AtCleanup_Portals(), we need to be careful not to clean up active portals too much. This mirrors similar code in PreCommit_Portals(). - PL/Perl Gets new functions spi_commit() and spi_rollback() - PL/pgSQL Gets new commands COMMIT and ROLLBACK. Update the PL/SQL porting example in the documentation to reflect that transactions are now possible in procedures. - PL/Python Gets new functions plpy.commit and plpy.rollback. - PL/Tcl Gets new commands commit and rollback. Reviewed-by: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
2018-01-22 14:30:16 +01:00
if (SPI_connect_ext(codeblock->atomic ? 0 : SPI_OPT_NONATOMIC) != SPI_OK_CONNECT)
Add support for anonymous code blocks (DO blocks) to PL/Perl. Joshua Tolley, reviewed by Brendan Jurd and Tim Bunce
2009-11-29 04:02:27 +01:00
elog(ERROR, "could not connect to SPI manager");
Various small improvements and cleanups for PL/Perl. - Allow (ineffective) use of 'require' in plperl If the required module is not already loaded then it dies. So "use strict;" now works in plperl. - Pre-load the feature module if perl >= 5.10. So "use feature :5.10;" now works in plperl. - Stored procedure subs are now given names. The names are not visible in ordinary use, but they make tools like Devel::NYTProf and Devel::Cover much more useful. - Simplified and generalized the subroutine creation code. Now one code path for generating sub source code, not four. Can generate multiple 'use' statements with specific imports (which handles plperl.use_strict currently and can easily be extended to handle a plperl.use_feature=':5.12' in future). - Disallows use of Safe version 2.20 which is broken for PL/Perl. http://rt.perl.org/rt3/Ticket/Display.html?id=72068 - Assorted minor optimizations by pre-growing data structures. Patch from Tim Bunce, reviewed by Alex Hunsaker.
2010-01-27 00:11:56 +01:00
select_perl_context(desc.lanpltrusted);
Add support for anonymous code blocks (DO blocks) to PL/Perl. Joshua Tolley, reviewed by Brendan Jurd and Tim Bunce
2009-11-29 04:02:27 +01:00
Various small improvements and cleanups for PL/Perl. - Allow (ineffective) use of 'require' in plperl If the required module is not already loaded then it dies. So "use strict;" now works in plperl. - Pre-load the feature module if perl >= 5.10. So "use feature :5.10;" now works in plperl. - Stored procedure subs are now given names. The names are not visible in ordinary use, but they make tools like Devel::NYTProf and Devel::Cover much more useful. - Simplified and generalized the subroutine creation code. Now one code path for generating sub source code, not four. Can generate multiple 'use' statements with specific imports (which handles plperl.use_strict currently and can easily be extended to handle a plperl.use_feature=':5.12' in future). - Disallows use of Safe version 2.20 which is broken for PL/Perl. http://rt.perl.org/rt3/Ticket/Display.html?id=72068 - Assorted minor optimizations by pre-growing data structures. Patch from Tim Bunce, reviewed by Alex Hunsaker.
2010-01-27 00:11:56 +01:00
plperl_create_sub(&desc, codeblock->source_text, 0);
Add support for anonymous code blocks (DO blocks) to PL/Perl. Joshua Tolley, reviewed by Brendan Jurd and Tim Bunce
2009-11-29 04:02:27 +01:00
if (!desc.reference) /* can this happen? */
elog(ERROR, "could not create internal procedure for anonymous code block");
Change function call information to be variable length. Before this change FunctionCallInfoData, the struct arguments etc for V1 function calls are stored in, always had space for FUNC_MAX_ARGS/100 arguments, storing datums and their nullness in two arrays. For nearly every function call 100 arguments is far more than needed, therefore wasting memory. Arg and argnull being two separate arrays also guarantees that to access a single argument, two cachelines have to be touched. Change the layout so there's a single variable-length array with pairs of value / isnull. That drastically reduces memory consumption for most function calls (on x86-64 a two argument function now uses 64bytes, previously 936 bytes), and makes it very likely that argument value and its nullness are on the same cacheline. Arguments are stored in a new NullableDatum struct, which, due to padding, needs more memory per argument than before. But as usually far fewer arguments are stored, and individual arguments are cheaper to access, that's still a clear win. It's likely that there's other places where conversion to NullableDatum arrays would make sense, e.g. TupleTableSlots, but that's for another commit. Because the function call information is now variable-length allocations have to take the number of arguments into account. For heap allocations that can be done with SizeForFunctionCallInfoData(), for on-stack allocations there's a new LOCAL_FCINFO(name, nargs) macro that helps to allocate an appropriately sized and aligned variable. Some places with stack allocation function call information don't know the number of arguments at compile time, and currently variably sized stack allocations aren't allowed in postgres. Therefore allow for FUNC_MAX_ARGS space in these cases. They're not that common, so for now that seems acceptable. Because of the need to allocate FunctionCallInfo of the appropriate size, older extensions may need to update their code. To avoid subtle breakages, the FunctionCallInfoData struct has been renamed to FunctionCallInfoBaseData. Most code only references FunctionCallInfo, so that shouldn't cause much collateral damage. This change is also a prerequisite for more efficient expression JIT compilation (by allocating the function call information on the stack, allowing LLVM to optimize it away); previously the size of the call information caused problems inside LLVM's optimizer. Author: Andres Freund Reviewed-By: Tom Lane Discussion: https://postgr.es/m/20180605172952.x34m5uz6ju6enaem@alap3.anarazel.de
2019-01-26 23:17:52 +01:00
perlret = plperl_call_perl_func(&desc, fake_fcinfo);
Add support for anonymous code blocks (DO blocks) to PL/Perl. Joshua Tolley, reviewed by Brendan Jurd and Tim Bunce
2009-11-29 04:02:27 +01:00
PL/Perl portability fix: avoid including XSUB.h in plperl.c. In Perl builds that define PERL_IMPLICIT_SYS, XSUB.h defines macros that replace a whole lot of basic libc functions with Perl functions. We can't tolerate that in plperl.c; it breaks at least PG_TRY and probably other stuff. The core idea of this patch is to include XSUB.h only in the .xs files where it's really needed, and to move any code broken by PERL_IMPLICIT_SYS out of the .xs files and into plperl.c. The reason this hasn't been a problem before is that our build techniques did not result in PERL_IMPLICIT_SYS appearing as a #define in PL/Perl, even on some platforms where Perl thinks it is defined. That's about to change in order to fix a nasty portability issue, so we need this work to make the code safe for that. Rather unaccountably, the Perl people chose XSUB.h as the place to provide the versions of the aTHX/aTHX_ macros that are needed by code that's not explicitly aware of the MULTIPLICITY API conventions. Hence, just removing XSUB.h from plperl.c fails miserably. But we can work around that by defining PERL_NO_GET_CONTEXT (which would make the relevant stanza of XSUB.h a no-op anyway). As explained in perlguts.pod, that means we need to add a "dTHX" macro call in every C function that calls a Perl API function. In most of them we just add this at the top; but since the macro fetches the current Perl interpreter pointer, more care is needed in functions that switch the active interpreter. Lack of the macro is easily recognized since it results in bleats about "my_perl" not being defined. (A nice side benefit of this is that it significantly reduces the number of fetches of the current interpreter pointer. On my machine, plperl.so gets more than 10% smaller, and there's probably some performance win too. We could reduce the number of fetches still more by decorating the code with pTHX_/aTHX_ macros to pass the interpreter pointer around, as explained by perlguts.pod; but that's a task for another day.) Formatting note: pgindent seems happy to treat "dTHX;" as a declaration so long as it's the first thing after the left brace, as we'd already observed with respect to the similar macro "dSP;". If you try to put it later in a set of declarations, pgindent puts ugly extra space around it. Having removed XSUB.h from plperl.c, we need only move the support functions for spi_return_next and util_elog (both of which use PG_TRY) out of the .xs files and into plperl.c. This seems sufficient to avoid the known problems caused by PERL_IMPLICIT_SYS, although we could move more code if additional issues emerge. This will need to be back-patched, but first let's see what the buildfarm makes of it. Patch by me, with some help from Ashutosh Sharma Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
2017-07-28 18:25:43 +02:00
SvREFCNT_dec_current(perlret);
Add support for anonymous code blocks (DO blocks) to PL/Perl. Joshua Tolley, reviewed by Brendan Jurd and Tim Bunce
2009-11-29 04:02:27 +01:00
if (SPI_finish() != SPI_OK_FINISH)
elog(ERROR, "SPI_finish() failed");
}
PG_FINALLY This gives an alternative way of catching exceptions, for the common case where the cleanup code is the same in the error and non-error cases. So instead of PG_TRY(); { ... code that might throw ereport(ERROR) ... } PG_CATCH(); { cleanup(); PG_RE_THROW(); } PG_END_TRY(); cleanup(); one can write PG_TRY(); { ... code that might throw ereport(ERROR) ... } PG_FINALLY(); { cleanup(); } PG_END_TRY(); Discussion: https://www.postgresql.org/message-id/flat/95a822c3-728b-af0e-d7e5-71890507ae0c%402ndquadrant.com
2019-11-01 11:09:52 +01:00
PG_FINALLY();
Add support for anonymous code blocks (DO blocks) to PL/Perl. Joshua Tolley, reviewed by Brendan Jurd and Tim Bunce
2009-11-29 04:02:27 +01:00
{
if (desc.reference)
PL/Perl portability fix: avoid including XSUB.h in plperl.c. In Perl builds that define PERL_IMPLICIT_SYS, XSUB.h defines macros that replace a whole lot of basic libc functions with Perl functions. We can't tolerate that in plperl.c; it breaks at least PG_TRY and probably other stuff. The core idea of this patch is to include XSUB.h only in the .xs files where it's really needed, and to move any code broken by PERL_IMPLICIT_SYS out of the .xs files and into plperl.c. The reason this hasn't been a problem before is that our build techniques did not result in PERL_IMPLICIT_SYS appearing as a #define in PL/Perl, even on some platforms where Perl thinks it is defined. That's about to change in order to fix a nasty portability issue, so we need this work to make the code safe for that. Rather unaccountably, the Perl people chose XSUB.h as the place to provide the versions of the aTHX/aTHX_ macros that are needed by code that's not explicitly aware of the MULTIPLICITY API conventions. Hence, just removing XSUB.h from plperl.c fails miserably. But we can work around that by defining PERL_NO_GET_CONTEXT (which would make the relevant stanza of XSUB.h a no-op anyway). As explained in perlguts.pod, that means we need to add a "dTHX" macro call in every C function that calls a Perl API function. In most of them we just add this at the top; but since the macro fetches the current Perl interpreter pointer, more care is needed in functions that switch the active interpreter. Lack of the macro is easily recognized since it results in bleats about "my_perl" not being defined. (A nice side benefit of this is that it significantly reduces the number of fetches of the current interpreter pointer. On my machine, plperl.so gets more than 10% smaller, and there's probably some performance win too. We could reduce the number of fetches still more by decorating the code with pTHX_/aTHX_ macros to pass the interpreter pointer around, as explained by perlguts.pod; but that's a task for another day.) Formatting note: pgindent seems happy to treat "dTHX;" as a declaration so long as it's the first thing after the left brace, as we'd already observed with respect to the similar macro "dSP;". If you try to put it later in a set of declarations, pgindent puts ugly extra space around it. Having removed XSUB.h from plperl.c, we need only move the support functions for spi_return_next and util_elog (both of which use PG_TRY) out of the .xs files and into plperl.c. This seems sufficient to avoid the known problems caused by PERL_IMPLICIT_SYS, although we could move more code if additional issues emerge. This will need to be back-patched, but first let's see what the buildfarm makes of it. Patch by me, with some help from Ashutosh Sharma Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
2017-07-28 18:25:43 +02:00
SvREFCNT_dec_current(desc.reference);
Fix bogus order of cleanup steps in plperl_inline_handler. Per Alex Hunsaker
2010-04-18 21:16:06 +02:00
current_call_data = save_call_data;
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
activate_interpreter(oldinterp);
Add support for anonymous code blocks (DO blocks) to PL/Perl. Joshua Tolley, reviewed by Brendan Jurd and Tim Bunce
2009-11-29 04:02:27 +01:00
}
PG_END_TRY();
error_context_stack = pl_error_context.previous;
PG_RETURN_VOID();
}
/*
* The validator is called during CREATE FUNCTION to validate the function
* being created/replaced. The precise behavior of the validator may be
* modified by the check_function_bodies GUC.
Add a validator function for plperl. Andrew Dunstan
2005-06-22 18:45:51 +02:00
*/
PG_FUNCTION_INFO_V1(plperl_validator);
Datum
plperl_validator(PG_FUNCTION_ARGS)
{
Oid funcoid = PG_GETARG_OID(0);
HeapTuple tuple;
Form_pg_proc proc;
Fix plperl validator to honor check_function_bodies: when that is OFF, we want it to check the argument/result data types and no more. In particular, libperl shouldn't get initialized in this case.
2005-12-28 19:34:16 +01:00
char functyptype;
Back out plperl OUT hash/array parameter patch, again.
2006-08-13 19:31:10 +02:00
int numargs;
Oid *argtypes;
char **argnames;
char *argmodes;
PL/Perl: Add event trigger support From: Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2013-12-11 14:11:59 +01:00
bool is_trigger = false;
bool is_event_trigger = false;
Back out plperl OUT hash/array parameter patch, again.
2006-08-13 19:31:10 +02:00
int i;
Add a validator function for plperl. Andrew Dunstan
2005-06-22 18:45:51 +02:00
Prevent privilege escalation in explicit calls to PL validators. The primary role of PL validators is to be called implicitly during CREATE FUNCTION, but they are also normal functions that a user can call explicitly. Add a permissions check to each validator to ensure that a user cannot use explicit validator calls to achieve things he could not otherwise achieve. Back-patch to 8.4 (all supported versions). Non-core procedural language extensions ought to make the same two-line change to their own validators. Andres Freund, reviewed by Tom Lane and Noah Misch. Security: CVE-2014-0061
2014-02-17 15:33:31 +01:00
if (!CheckFunctionValidatorAccess(fcinfo->flinfo->fn_oid, funcoid))
PG_RETURN_VOID();
Add a validator function for plperl. Andrew Dunstan
2005-06-22 18:45:51 +02:00
/* Get the new function's pg_proc entry */
Wrap calls to SearchSysCache and related functions using macros. The purpose of this change is to eliminate the need for every caller of SearchSysCache, SearchSysCacheCopy, SearchSysCacheExists, GetSysCacheOid, and SearchSysCacheList to know the maximum number of allowable keys for a syscache entry (currently 4). This will make it far easier to increase the maximum number of keys in a future release should we choose to do so, and it makes the code shorter, too. Design and review by Tom Lane.
2010-02-14 19:42:19 +01:00
tuple = SearchSysCache1(PROCOID, ObjectIdGetDatum(funcoid));
Add a validator function for plperl. Andrew Dunstan
2005-06-22 18:45:51 +02:00
if (!HeapTupleIsValid(tuple))
elog(ERROR, "cache lookup failed for function %u", funcoid);
proc = (Form_pg_proc) GETSTRUCT(tuple);
Fix plperl validator to honor check_function_bodies: when that is OFF, we want it to check the argument/result data types and no more. In particular, libperl shouldn't get initialized in this case.
2005-12-28 19:34:16 +01:00
functyptype = get_typtype(proc->prorettype);
/* Disallow pseudotype result */
PL/Perl: Add event trigger support From: Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2013-12-11 14:11:59 +01:00
/* except for TRIGGER, EVTTRIGGER, RECORD, or VOID */
Support enum data types. Along the way, use macros for the values of pg_type.typtype whereever practical. Tom Dunstan, with some kibitzing from Tom Lane.
2007-04-02 05:49:42 +02:00
if (functyptype == TYPTYPE_PSEUDO)
Fix plperl validator to honor check_function_bodies: when that is OFF, we want it to check the argument/result data types and no more. In particular, libperl shouldn't get initialized in this case.
2005-12-28 19:34:16 +01:00
{
Remove the "opaque" pseudo-type and associated compatibility hacks. A long time ago, it was necessary to declare datatype I/O functions, triggers, and language handler support functions in a very type-unsafe way involving a single pseudo-type "opaque". We got rid of those conventions in 7.3, but there was still support in various places to automatically convert such functions to the modern declaration style, to be able to transparently re-load dumps from pre-7.3 servers. It seems unnecessary to continue to support that anymore, so take out the hacks; whereupon the "opaque" pseudo-type itself is no longer needed and can be dropped. This is part of a group of patches removing various server-side kluges for transparently upgrading pre-8.0 dump files. Since we've had few complaints about dropping pg_dump's support for dumping from pre-8.0 servers (commit 64f3524e2), it seems okay to now remove these kluges. Discussion: https://postgr.es/m/4110.1583255415@sss.pgh.pa.us
2020-03-05 21:48:56 +01:00
if (proc->prorettype == TRIGGEROID)
PL/Perl: Add event trigger support From: Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2013-12-11 14:11:59 +01:00
is_trigger = true;
Don't use custom OID symbols in pg_type.dat, either. On the same reasoning as in commit 36b931214, forbid using custom oid_symbol macros in pg_type as well as pg_proc, so that we always rely on the predictable macro names generated by genbki.pl. We do continue to grant grandfather status to the names CASHOID and LSNOID, although those are now considered deprecated aliases for the preferred names MONEYOID and PG_LSNOID. This is because there's likely to be client-side code using the old names, and this bout of neatnik-ism doesn't quite seem worth breaking client code. There might be a case for grandfathering EVTTRIGGEROID, too, since externally-maintained PLs may reference that symbol. But renaming such references to EVENT_TRIGGEROID doesn't seem like a particularly heavy lift --- we make far more significant backend API changes in every major release. For now I didn't add that, but we could reconsider if there's pushback. The other names changed here seem pretty unlikely to have any outside uses. Again, we could add alias macros if there are complaints, but for now I didn't. As before, no need for a catversion bump. John Naylor Discussion: https://postgr.es/m/CAFBsxsHpCbjfoddNGpnnnY5pHwckWfiYkMYSF74PmP1su0+ZOw@mail.gmail.com
2020-10-29 18:33:38 +01:00
else if (proc->prorettype == EVENT_TRIGGEROID)
PL/Perl: Add event trigger support From: Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2013-12-11 14:11:59 +01:00
is_event_trigger = true;
Fix plperl validator to honor check_function_bodies: when that is OFF, we want it to check the argument/result data types and no more. In particular, libperl shouldn't get initialized in this case.
2005-12-28 19:34:16 +01:00
else if (proc->prorettype != RECORDOID &&
proc->prorettype != VOIDOID)
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
Wordsmithing for PL/Perl messages
2009-02-19 11:33:17 +01:00
errmsg("PL/Perl functions cannot return type %s",
Fix plperl validator to honor check_function_bodies: when that is OFF, we want it to check the argument/result data types and no more. In particular, libperl shouldn't get initialized in this case.
2005-12-28 19:34:16 +01:00
format_type_be(proc->prorettype))));
}
Back out plperl OUT hash/array parameter patch, again.
2006-08-13 19:31:10 +02:00
/* Disallow pseudotypes in arguments (either IN or OUT) */
numargs = get_func_arg_info(tuple,
&argtypes, &argnames, &argmodes);
for (i = 0; i < numargs; i++)
{
Remove useless whitespace at end of lines
2010-11-23 21:27:50 +01:00
if (get_typtype(argtypes[i]) == TYPTYPE_PSEUDO &&
Allow generic record arguments to plperl functions
2010-10-29 02:48:12 +02:00
argtypes[i] != RECORDOID)
Back out plperl OUT hash/array parameter patch, again.
2006-08-13 19:31:10 +02:00
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
Wordsmithing for PL/Perl messages
2009-02-19 11:33:17 +01:00
errmsg("PL/Perl functions cannot accept type %s",
Back out plperl OUT hash/array parameter patch, again.
2006-08-13 19:31:10 +02:00
format_type_be(argtypes[i]))));
}
Add a validator function for plperl. Andrew Dunstan
2005-06-22 18:45:51 +02:00
ReleaseSysCache(tuple);
Fix plperl validator to honor check_function_bodies: when that is OFF, we want it to check the argument/result data types and no more. In particular, libperl shouldn't get initialized in this case.
2005-12-28 19:34:16 +01:00
/* Postpone body checks if !check_function_bodies */
if (check_function_bodies)
{
PL/Perl: Add event trigger support From: Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2013-12-11 14:11:59 +01:00
(void) compile_plperl_function(funcoid, is_trigger, is_event_trigger);
Fix plperl validator to honor check_function_bodies: when that is OFF, we want it to check the argument/result data types and no more. In particular, libperl shouldn't get initialized in this case.
2005-12-28 19:34:16 +01:00
}
Add a validator function for plperl. Andrew Dunstan
2005-06-22 18:45:51 +02:00
/* the result of a validator is ignored */
PG_RETURN_VOID();
}
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
Create extension infrastructure for the core procedural languages. This mostly just involves creating control, install, and update-from-unpackaged scripts for them. However, I had to adjust plperl and plpython to not share the same support functions between variants, because we can't put the same function into multiple extensions. catversion bump forced due to new contents of pg_pltemplate, and because initdb now installs plpgsql as an extension not a bare language. Add support for regression testing these as extensions not bare languages. Fix a couple of other issues that popped up while testing this: my initial hack at pg_dump binary-upgrade support didn't work right, and we don't want an extra schema permissions test after all. Documentation changes still to come, but I'm committing now to see whether the MSVC build scripts need work (likely they do).
2011-03-05 03:51:14 +01:00
/*
* plperlu likewise requires three externally visible functions:
* plperlu_call_handler, plperlu_inline_handler, and plperlu_validator.
* These are currently just aliases that send control to the plperl
* handler functions, and we decide whether a particular function is
* trusted or not by inspecting the actual pg_language tuple.
*/
PG_FUNCTION_INFO_V1(plperlu_call_handler);
Datum
plperlu_call_handler(PG_FUNCTION_ARGS)
{
return plperl_call_handler(fcinfo);
}
PG_FUNCTION_INFO_V1(plperlu_inline_handler);
Datum
plperlu_inline_handler(PG_FUNCTION_ARGS)
{
return plperl_inline_handler(fcinfo);
}
PG_FUNCTION_INFO_V1(plperlu_validator);
Datum
plperlu_validator(PG_FUNCTION_ARGS)
{
Prevent privilege escalation in explicit calls to PL validators. The primary role of PL validators is to be called implicitly during CREATE FUNCTION, but they are also normal functions that a user can call explicitly. Add a permissions check to each validator to ensure that a user cannot use explicit validator calls to achieve things he could not otherwise achieve. Back-patch to 8.4 (all supported versions). Non-core procedural language extensions ought to make the same two-line change to their own validators. Andres Freund, reviewed by Tom Lane and Noah Misch. Security: CVE-2014-0061
2014-02-17 15:33:31 +01:00
/* call plperl validator with our fcinfo so it gets our oid */
Create extension infrastructure for the core procedural languages. This mostly just involves creating control, install, and update-from-unpackaged scripts for them. However, I had to adjust plperl and plpython to not share the same support functions between variants, because we can't put the same function into multiple extensions. catversion bump forced due to new contents of pg_pltemplate, and because initdb now installs plpgsql as an extension not a bare language. Add support for regression testing these as extensions not bare languages. Fix a couple of other issues that popped up while testing this: my initial hack at pg_dump binary-upgrade support didn't work right, and we don't want an extra schema permissions test after all. Documentation changes still to come, but I'm committing now to see whether the MSVC build scripts need work (likely they do).
2011-03-05 03:51:14 +01:00
return plperl_validator(fcinfo);
}
Adjust plperl to ensure that all strings and hash keys passed to Perl are marked as UTF8 when the database encoding is UTF8. This should avoid inconsistencies like that exhibited in bug #2683 from Vitali Stupin.
2006-10-15 20:56:39 +02:00
/*
Fix inconsistencies and typos in the tree This is numbered take 8, and addresses again a set of issues with code comments, variable names and unreferenced variables. Author: Alexander Lakhin Discussion: https://postgr.es/m/b137b5eb-9c95-9c2f-586e-38aba7d59788@gmail.com
2019-07-29 05:28:30 +02:00
* Uses mkfunc to create a subroutine whose text is
Various small improvements and cleanups for PL/Perl. - Allow (ineffective) use of 'require' in plperl If the required module is not already loaded then it dies. So "use strict;" now works in plperl. - Pre-load the feature module if perl >= 5.10. So "use feature :5.10;" now works in plperl. - Stored procedure subs are now given names. The names are not visible in ordinary use, but they make tools like Devel::NYTProf and Devel::Cover much more useful. - Simplified and generalized the subroutine creation code. Now one code path for generating sub source code, not four. Can generate multiple 'use' statements with specific imports (which handles plperl.use_strict currently and can easily be extended to handle a plperl.use_feature=':5.12' in future). - Disallows use of Safe version 2.20 which is broken for PL/Perl. http://rt.perl.org/rt3/Ticket/Display.html?id=72068 - Assorted minor optimizations by pre-growing data structures. Patch from Tim Bunce, reviewed by Alex Hunsaker.
2010-01-27 00:11:56 +01:00
* supplied in s, and returns a reference to it
Adjust plperl to ensure that all strings and hash keys passed to Perl are marked as UTF8 when the database encoding is UTF8. This should avoid inconsistencies like that exhibited in bug #2683 from Vitali Stupin.
2006-10-15 20:56:39 +02:00
*/
Tidy up and refactor plperl.c. - Changed MULTIPLICITY check from runtime to compiletime. No loads the large Config module. - Changed plperl_init_interp() to return new interp and not alter the global interp_state - Moved plperl_safe_init() call into check_interp(). - Removed plperl_safe_init_done state variable as interp_state now covers that role. - Changed plperl_create_sub() to take a plperl_proc_desc argument. - Simplified return value handling in plperl_create_sub. - Changed perl.com link in the docs to perl.org and tweaked wording to clarify that require, not use, is what's blocked. - Moved perl code in large multi-line C string literal macros out to plc_*.pl files. - Added a test2macro.pl utility to convert the plc_*.pl files to macros in a perlchunks.h file which is #included - Simplifed plperl_safe_init() slightly - Optimized pg_verifymbstr calls to avoid unneeded strlen()s. Patch from Tim Bunce, with minor editing from me.
2010-01-09 03:40:50 +01:00
static void
Add some const decorations to prototypes Reviewed-by: Fabien COELHO <coelho@cri.ensmp.fr>
2017-10-31 15:34:31 +01:00
plperl_create_sub(plperl_proc_desc *prodesc, const char *s, Oid fn_oid)
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
{
PL/Perl portability fix: avoid including XSUB.h in plperl.c. In Perl builds that define PERL_IMPLICIT_SYS, XSUB.h defines macros that replace a whole lot of basic libc functions with Perl functions. We can't tolerate that in plperl.c; it breaks at least PG_TRY and probably other stuff. The core idea of this patch is to include XSUB.h only in the .xs files where it's really needed, and to move any code broken by PERL_IMPLICIT_SYS out of the .xs files and into plperl.c. The reason this hasn't been a problem before is that our build techniques did not result in PERL_IMPLICIT_SYS appearing as a #define in PL/Perl, even on some platforms where Perl thinks it is defined. That's about to change in order to fix a nasty portability issue, so we need this work to make the code safe for that. Rather unaccountably, the Perl people chose XSUB.h as the place to provide the versions of the aTHX/aTHX_ macros that are needed by code that's not explicitly aware of the MULTIPLICITY API conventions. Hence, just removing XSUB.h from plperl.c fails miserably. But we can work around that by defining PERL_NO_GET_CONTEXT (which would make the relevant stanza of XSUB.h a no-op anyway). As explained in perlguts.pod, that means we need to add a "dTHX" macro call in every C function that calls a Perl API function. In most of them we just add this at the top; but since the macro fetches the current Perl interpreter pointer, more care is needed in functions that switch the active interpreter. Lack of the macro is easily recognized since it results in bleats about "my_perl" not being defined. (A nice side benefit of this is that it significantly reduces the number of fetches of the current interpreter pointer. On my machine, plperl.so gets more than 10% smaller, and there's probably some performance win too. We could reduce the number of fetches still more by decorating the code with pTHX_/aTHX_ macros to pass the interpreter pointer around, as explained by perlguts.pod; but that's a task for another day.) Formatting note: pgindent seems happy to treat "dTHX;" as a declaration so long as it's the first thing after the left brace, as we'd already observed with respect to the similar macro "dSP;". If you try to put it later in a set of declarations, pgindent puts ugly extra space around it. Having removed XSUB.h from plperl.c, we need only move the support functions for spi_return_next and util_elog (both of which use PG_TRY) out of the .xs files and into plperl.c. This seems sufficient to avoid the known problems caused by PERL_IMPLICIT_SYS, although we could move more code if additional issues emerge. This will need to be back-patched, but first let's see what the buildfarm makes of it. Patch by me, with some help from Ashutosh Sharma Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
2017-07-28 18:25:43 +02:00
dTHX;
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
dSP;
Various small improvements and cleanups for PL/Perl. - Allow (ineffective) use of 'require' in plperl If the required module is not already loaded then it dies. So "use strict;" now works in plperl. - Pre-load the feature module if perl >= 5.10. So "use feature :5.10;" now works in plperl. - Stored procedure subs are now given names. The names are not visible in ordinary use, but they make tools like Devel::NYTProf and Devel::Cover much more useful. - Simplified and generalized the subroutine creation code. Now one code path for generating sub source code, not four. Can generate multiple 'use' statements with specific imports (which handles plperl.use_strict currently and can easily be extended to handle a plperl.use_feature=':5.12' in future). - Disallows use of Safe version 2.20 which is broken for PL/Perl. http://rt.perl.org/rt3/Ticket/Display.html?id=72068 - Assorted minor optimizations by pre-growing data structures. Patch from Tim Bunce, reviewed by Alex Hunsaker.
2010-01-27 00:11:56 +01:00
char subname[NAMEDATALEN + 40];
HV *pragma_hv = newHV();
SV *subref = NULL;
int count;
sprintf(subname, "%s__%u", prodesc->proname, fn_oid);
if (plperl_use_strict)
hv_store_string(pragma_hv, "strict", (SV *) newAV());
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
ENTER;
SAVETMPS;
PUSHMARK(SP);
Various small improvements and cleanups for PL/Perl. - Allow (ineffective) use of 'require' in plperl If the required module is not already loaded then it dies. So "use strict;" now works in plperl. - Pre-load the feature module if perl >= 5.10. So "use feature :5.10;" now works in plperl. - Stored procedure subs are now given names. The names are not visible in ordinary use, but they make tools like Devel::NYTProf and Devel::Cover much more useful. - Simplified and generalized the subroutine creation code. Now one code path for generating sub source code, not four. Can generate multiple 'use' statements with specific imports (which handles plperl.use_strict currently and can easily be extended to handle a plperl.use_feature=':5.12' in future). - Disallows use of Safe version 2.20 which is broken for PL/Perl. http://rt.perl.org/rt3/Ticket/Display.html?id=72068 - Assorted minor optimizations by pre-growing data structures. Patch from Tim Bunce, reviewed by Alex Hunsaker.
2010-01-27 00:11:56 +01:00
EXTEND(SP, 4);
Force strings passed to and from plperl to be in UTF8 encoding. String are converted to UTF8 on the way into perl and to the database encoding on the way back. This avoids a number of observed anomalies, and ensures Perl a consistent view of the world. Some minor code cleanups are also accomplished. Alex Hunsaker, reviewed by Andy Colson.
2011-02-06 23:29:26 +01:00
PUSHs(sv_2mortal(cstr2sv(subname)));
Various small improvements and cleanups for PL/Perl. - Allow (ineffective) use of 'require' in plperl If the required module is not already loaded then it dies. So "use strict;" now works in plperl. - Pre-load the feature module if perl >= 5.10. So "use feature :5.10;" now works in plperl. - Stored procedure subs are now given names. The names are not visible in ordinary use, but they make tools like Devel::NYTProf and Devel::Cover much more useful. - Simplified and generalized the subroutine creation code. Now one code path for generating sub source code, not four. Can generate multiple 'use' statements with specific imports (which handles plperl.use_strict currently and can easily be extended to handle a plperl.use_feature=':5.12' in future). - Disallows use of Safe version 2.20 which is broken for PL/Perl. http://rt.perl.org/rt3/Ticket/Display.html?id=72068 - Assorted minor optimizations by pre-growing data structures. Patch from Tim Bunce, reviewed by Alex Hunsaker.
2010-01-27 00:11:56 +01:00
PUSHs(sv_2mortal(newRV_noinc((SV *) pragma_hv)));
pgindent run on plperl.c
2011-02-17 20:40:13 +01:00
/*
* Use 'false' for $prolog in mkfunc, which is kept for compatibility in
* case a module such as PostgreSQL::PLPerl::NYTprof replaces the function
* compiler.
Add comment on why we're passing a useless 'false' to the plperl function compiler. It's for compatibility with modules like PostgreSQL::PLPerl::NYTProf.
2011-02-02 18:45:42 +01:00
*/
pgindent run on plperl.c
2011-02-17 20:40:13 +01:00
PUSHs(&PL_sv_no);
Force strings passed to and from plperl to be in UTF8 encoding. String are converted to UTF8 on the way into perl and to the database encoding on the way back. This avoids a number of observed anomalies, and ensures Perl a consistent view of the world. Some minor code cleanups are also accomplished. Alex Hunsaker, reviewed by Andy Colson.
2011-02-06 23:29:26 +01:00
PUSHs(sv_2mortal(cstr2sv(s)));
Security fix for plperl.
2000-04-18 17:04:02 +02:00
PUTBACK;
pgindent run.
2003-08-04 02:43:34 +02:00
Fix multiple causes of breakage in plperl's error handling.
2003-04-20 23:15:34 +02:00
/*
* G_KEEPERR seems to be needed here, else we don't recognize compile
* errors properly. Perhaps it's because there's another level of eval
Fix typos in comments The changes done in this commit impact comments with no direct user-visible changes, with fixes for incorrect function, variable or structure names. Author: Alexander Lakhin Discussion: https://postgr.es/m/e8c38840-596a-83d6-bd8d-cebc51111572@gmail.com
2023-05-02 05:23:08 +02:00
* inside mkfunc?
Fix multiple causes of breakage in plperl's error handling.
2003-04-20 23:15:34 +02:00
*/
plperl: update ppport.h to Perl 5.34.0. Also apply the changes suggested by running perl ppport.h --compat-version=5.8.0 And remove some no-longer-required NEED_foo declarations. Dagfinn Ilmari Mannsåker Discussion: https://postgr.es/m/87y278s6iq.fsf@wibble.ilmari.org
2021-10-07 19:59:43 +02:00
count = call_pv("PostgreSQL::InServer::mkfunc",
G_SCALAR | G_EVAL | G_KEEPERR);
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
SPAGAIN;
Various small improvements and cleanups for PL/Perl. - Allow (ineffective) use of 'require' in plperl If the required module is not already loaded then it dies. So "use strict;" now works in plperl. - Pre-load the feature module if perl >= 5.10. So "use feature :5.10;" now works in plperl. - Stored procedure subs are now given names. The names are not visible in ordinary use, but they make tools like Devel::NYTProf and Devel::Cover much more useful. - Simplified and generalized the subroutine creation code. Now one code path for generating sub source code, not four. Can generate multiple 'use' statements with specific imports (which handles plperl.use_strict currently and can easily be extended to handle a plperl.use_feature=':5.12' in future). - Disallows use of Safe version 2.20 which is broken for PL/Perl. http://rt.perl.org/rt3/Ticket/Display.html?id=72068 - Assorted minor optimizations by pre-growing data structures. Patch from Tim Bunce, reviewed by Alex Hunsaker.
2010-01-27 00:11:56 +01:00
if (count == 1)
{
Abandon the use of Perl's Safe.pm to enforce restrictions in plperl, as it is fundamentally insecure. Instead apply an opmask to the whole interpreter that imposes restrictions on unsafe operations. These restrictions are much harder to subvert than is Safe.pm, since there is no container to be broken out of. Backported to release 7.4. In releases 7.4, 8.0 and 8.1 this also includes the necessary backporting of the two interpreters model for plperl and plperlu adopted in release 8.2. In versions 8.0 and up, the use of Perl's POSIX module to undo its locale mangling on Windows has become insecure with these changes, so it is replaced by our own routine, which is also faster. Nice side effects of the changes include that it is now possible to use perl's "strict" pragma in a natural way in plperl, and that perl's $a and $b variables now work as expected in sort routines, and that function compilation is significantly faster. Tim Bunce and Andrew Dunstan, with reviews from Alex Hunsaker and Alexey Klyukin. Security: CVE-2010-1169
2010-05-13 18:39:43 +02:00
SV *sub_rv = (SV *) POPs;
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
Abandon the use of Perl's Safe.pm to enforce restrictions in plperl, as it is fundamentally insecure. Instead apply an opmask to the whole interpreter that imposes restrictions on unsafe operations. These restrictions are much harder to subvert than is Safe.pm, since there is no container to be broken out of. Backported to release 7.4. In releases 7.4, 8.0 and 8.1 this also includes the necessary backporting of the two interpreters model for plperl and plperlu adopted in release 8.2. In versions 8.0 and up, the use of Perl's POSIX module to undo its locale mangling on Windows has become insecure with these changes, so it is replaced by our own routine, which is also faster. Nice side effects of the changes include that it is now possible to use perl's "strict" pragma in a natural way in plperl, and that perl's $a and $b variables now work as expected in sort routines, and that function compilation is significantly faster. Tim Bunce and Andrew Dunstan, with reviews from Alex Hunsaker and Alexey Klyukin. Security: CVE-2010-1169
2010-05-13 18:39:43 +02:00
if (sub_rv && SvROK(sub_rv) && SvTYPE(SvRV(sub_rv)) == SVt_PVCV)
Fix bug found by warning from recent gcc. patch from Tim Bunce.
2010-01-29 00:06:09 +01:00
{
Abandon the use of Perl's Safe.pm to enforce restrictions in plperl, as it is fundamentally insecure. Instead apply an opmask to the whole interpreter that imposes restrictions on unsafe operations. These restrictions are much harder to subvert than is Safe.pm, since there is no container to be broken out of. Backported to release 7.4. In releases 7.4, 8.0 and 8.1 this also includes the necessary backporting of the two interpreters model for plperl and plperlu adopted in release 8.2. In versions 8.0 and up, the use of Perl's POSIX module to undo its locale mangling on Windows has become insecure with these changes, so it is replaced by our own routine, which is also faster. Nice side effects of the changes include that it is now possible to use perl's "strict" pragma in a natural way in plperl, and that perl's $a and $b variables now work as expected in sort routines, and that function compilation is significantly faster. Tim Bunce and Andrew Dunstan, with reviews from Alex Hunsaker and Alexey Klyukin. Security: CVE-2010-1169
2010-05-13 18:39:43 +02:00
subref = newRV_inc(SvRV(sub_rv));
Fix bug found by warning from recent gcc. patch from Tim Bunce.
2010-01-29 00:06:09 +01:00
}
Fix multiple causes of breakage in plperl's error handling.
2003-04-20 23:15:34 +02:00
}
Various small improvements and cleanups for PL/Perl. - Allow (ineffective) use of 'require' in plperl If the required module is not already loaded then it dies. So "use strict;" now works in plperl. - Pre-load the feature module if perl >= 5.10. So "use feature :5.10;" now works in plperl. - Stored procedure subs are now given names. The names are not visible in ordinary use, but they make tools like Devel::NYTProf and Devel::Cover much more useful. - Simplified and generalized the subroutine creation code. Now one code path for generating sub source code, not four. Can generate multiple 'use' statements with specific imports (which handles plperl.use_strict currently and can easily be extended to handle a plperl.use_feature=':5.12' in future). - Disallows use of Safe version 2.20 which is broken for PL/Perl. http://rt.perl.org/rt3/Ticket/Display.html?id=72068 - Assorted minor optimizations by pre-growing data structures. Patch from Tim Bunce, reviewed by Alex Hunsaker.
2010-01-27 00:11:56 +01:00
PUTBACK;
FREETMPS;
LEAVE;
Tidy up and refactor plperl.c. - Changed MULTIPLICITY check from runtime to compiletime. No loads the large Config module. - Changed plperl_init_interp() to return new interp and not alter the global interp_state - Moved plperl_safe_init() call into check_interp(). - Removed plperl_safe_init_done state variable as interp_state now covers that role. - Changed plperl_create_sub() to take a plperl_proc_desc argument. - Simplified return value handling in plperl_create_sub. - Changed perl.com link in the docs to perl.org and tweaked wording to clarify that require, not use, is what's blocked. - Moved perl code in large multi-line C string literal macros out to plc_*.pl files. - Added a test2macro.pl utility to convert the plc_*.pl files to macros in a perlchunks.h file which is #included - Simplifed plperl_safe_init() slightly - Optimized pg_verifymbstr calls to avoid unneeded strlen()s. Patch from Tim Bunce, with minor editing from me.
2010-01-09 03:40:50 +01:00
This patch, when applied in src/pl will unbreak plperl in 7.0.2 release. Sorry, if that's fixed ages ago - I don't track development versions of PostgreSQL. Patch is just a little bit tested (some valid functions created and successfully run as well as some erroneous ones created and emitted proper error messages when used). My platform is FreeBSD 5.0-CURRENT (with perl 5.6.0 provided in the base system). Alex Kapranoff
2000-09-12 06:28:30 +02:00
if (SvTRUE(ERRSV))
Update plperl to use ereport() not elog() for user-facing messages, so that they will be translatable. Give messages some semblance of conformance to the style guide.
2004-11-29 21:11:06 +01:00
ereport(ERROR,
(errcode(ERRCODE_SYNTAX_ERROR),
Force strings passed to and from plperl to be in UTF8 encoding. String are converted to UTF8 on the way into perl and to the database encoding on the way back. This avoids a number of observed anomalies, and ensures Perl a consistent view of the world. Some minor code cleanups are also accomplished. Alex Hunsaker, reviewed by Andy Colson.
2011-02-06 23:29:26 +01:00
errmsg("%s", strip_trailing_ws(sv2cstr(ERRSV)))));
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
Various small improvements and cleanups for PL/Perl. - Allow (ineffective) use of 'require' in plperl If the required module is not already loaded then it dies. So "use strict;" now works in plperl. - Pre-load the feature module if perl >= 5.10. So "use feature :5.10;" now works in plperl. - Stored procedure subs are now given names. The names are not visible in ordinary use, but they make tools like Devel::NYTProf and Devel::Cover much more useful. - Simplified and generalized the subroutine creation code. Now one code path for generating sub source code, not four. Can generate multiple 'use' statements with specific imports (which handles plperl.use_strict currently and can easily be extended to handle a plperl.use_feature=':5.12' in future). - Disallows use of Safe version 2.20 which is broken for PL/Perl. http://rt.perl.org/rt3/Ticket/Display.html?id=72068 - Assorted minor optimizations by pre-growing data structures. Patch from Tim Bunce, reviewed by Alex Hunsaker.
2010-01-27 00:11:56 +01:00
if (!subref)
ereport(ERROR,
Fix a number of places that produced XX000 errors in the regression tests. It's against project policy to use elog() for user-facing errors, or to omit an errcode() selection for errors that aren't supposed to be "can't happen" cases. Fix all the violations of this policy that result in ERRCODE_INTERNAL_ERROR log entries during the standard regression tests, as errors that can reliably be triggered from SQL surely should be considered user-facing. I also looked through all the files touched by this commit and fixed other nearby problems of the same ilk. I do not claim to have fixed all violations of the policy, just the ones in these files. In a few places I also changed existing ERRCODE choices that didn't seem particularly appropriate; mainly replacing ERRCODE_SYNTAX_ERROR by something more specific. Back-patch to 9.5, but no further; changing ERRCODE assignments in stable branches doesn't seem like a good idea.
2015-08-03 05:49:19 +02:00
(errcode(ERRCODE_SYNTAX_ERROR),
errmsg("didn't get a CODE reference from compiling function \"%s\"",
Abandon the use of Perl's Safe.pm to enforce restrictions in plperl, as it is fundamentally insecure. Instead apply an opmask to the whole interpreter that imposes restrictions on unsafe operations. These restrictions are much harder to subvert than is Safe.pm, since there is no container to be broken out of. Backported to release 7.4. In releases 7.4, 8.0 and 8.1 this also includes the necessary backporting of the two interpreters model for plperl and plperlu adopted in release 8.2. In versions 8.0 and up, the use of Perl's POSIX module to undo its locale mangling on Windows has become insecure with these changes, so it is replaced by our own routine, which is also faster. Nice side effects of the changes include that it is now possible to use perl's "strict" pragma in a natural way in plperl, and that perl's $a and $b variables now work as expected in sort routines, and that function compilation is significantly faster. Tim Bunce and Andrew Dunstan, with reviews from Alex Hunsaker and Alexey Klyukin. Security: CVE-2010-1169
2010-05-13 18:39:43 +02:00
prodesc->proname)));
pgindent run for 9.0, second run
2010-07-06 21:19:02 +02:00
Abandon the use of Perl's Safe.pm to enforce restrictions in plperl, as it is fundamentally insecure. Instead apply an opmask to the whole interpreter that imposes restrictions on unsafe operations. These restrictions are much harder to subvert than is Safe.pm, since there is no container to be broken out of. Backported to release 7.4. In releases 7.4, 8.0 and 8.1 this also includes the necessary backporting of the two interpreters model for plperl and plperlu adopted in release 8.2. In versions 8.0 and up, the use of Perl's POSIX module to undo its locale mangling on Windows has become insecure with these changes, so it is replaced by our own routine, which is also faster. Nice side effects of the changes include that it is now possible to use perl's "strict" pragma in a natural way in plperl, and that perl's $a and $b variables now work as expected in sort routines, and that function compilation is significantly faster. Tim Bunce and Andrew Dunstan, with reviews from Alex Hunsaker and Alexey Klyukin. Security: CVE-2010-1169
2010-05-13 18:39:43 +02:00
prodesc->reference = subref;
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
}
At 2005-05-21 20:18:50 +0530, ams@oryx.com wrote: > > > The second issue is where plperl returns a large result set. I have attached the following seven patches to address this problem: 1. Trivial. Replaces some errant spaces with tabs. 2. Trivial. Fixes the spelling of Jan's name, and gets rid of many inane, useless, annoying, and often misleading comments. Here's a sample: "plperl_init_all() - Initialize all". (I have tried to add some useful comments here and there, and will continue to do so now and again.) 3. Trivial. Splits up some long lines. 4. Converts SRFs in PL/Perl to use a Tuplestore and SFRM_Materialize to return the result set, based on the PL/PgSQL model. There are two major consequences: result sets will spill to disk when they can no longer fit in work_mem; and "select foo_srf()" no longer works. (I didn't lose sleep over the latter, since that form is not valid in PL/PgSQL, and it's not documented in PL/Perl.) 5. Trivial, but important. Fixes use of "undef" instead of undef. This would cause empty functions to fail in bizarre ways. I suspect that there's still another (old) bug here. I'll investigate further. 6. Moves the majority of (4) out into a new plperl_return_next() function, to make it possible to expose the functionality to Perl; cleans up some of the code besides. 7. Add an spi_return_next function for use in Perl code. If you want to apply the patches and try them out, 8-composite.diff is what you should use. (Note: my patches depend upon Andrew's use-strict and %_SHARED patches being applied.) Here's something to try: create or replace function foo() returns setof record as $$ $i = 0; for ("World", "PostgreSQL", "PL/Perl") { spi_return_next({f1=>++$i, f2=>'Hello', f3=>$_}); } return; $$ language plperl; select * from foo() as (f1 integer, f2 text, f3 text); (Many thanks to Andrews Dunstan and Supernews for their help.) Abhijit Menon-Sen
2005-06-04 22:33:06 +02:00
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
/**********************************************************************
* plperl_init_shared_libs() -
**********************************************************************/
HP's compiler objects (quite rightly too) to 'static void foo();' followed by 'extern void foo() { ... }'.
2000-02-19 19:58:37 +01:00
static void
Tweak plperl.c to compile against threaded Perls, per report from cturner@redhat.com.
2002-01-24 22:40:44 +01:00
plperl_init_shared_libs(pTHX)
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
{
char *file = __FILE__;
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
Well, after persuading cvsup and cvs that it _is_ possible to have local modifiable repositories, I have a clean untrusted plperl patch to offer you :) Highlights: * There's one perl interpreter used for both trusted and untrusted procedures. I do think its unnecessary to keep two perl interpreters around. If someone can break out from trusted "Safe" perl mode, well, they can do what they want already. If someone disagrees, I can change this. * Opcode is not statically loaded anymore. Instead, we load Dynaloader, which then can grab Opcode (and anything else you can 'use') on its own. * Checked to work on FreeBSD 4.3 + perl 5.5.3 , OpenBSD 2.8 + perl5.6.1, RedHat 6.2 + perl 5.5.3 * Uses ExtUtils::Embed to find what options are necessary to link with perl shared libraries * createlang is also updated, it can create untrusted perl using 'plperlu' * Example script (assuming you have Mail::Sendmail installed): create function foo() returns text as ' use Mail::Sendmail; %mail = ( To => q(you@yourname.com), From => q(me@here.com), Message => "This is a very short message" ); sendmail(%mail) or die $Mail::Sendmail::error; return "OK. Log says:\n", $Mail::Sendmail::log; ' language 'plperlu'; Alex Pilosov
2001-06-18 23:40:06 +02:00
newXS("DynaLoader::boot_DynaLoader", boot_DynaLoader, file);
Add utility functions to PLPerl: quote_literal, quote_nullable, quote_ident, encode_bytea, decode_bytea, looks_like_number, encode_array_literal, encode_array_constructor. Split SPI.xs into two - SPI.xs now contains only SPI functions. Remainder are in new Util.xs. Some more code and documentation cleanup along the way, as well as adding some CVS markers to files missing them. Original patch from Tim Bunce, with a little editing from me.
2010-01-20 02:08:21 +01:00
newXS("PostgreSQL::InServer::Util::bootstrap",
boot_PostgreSQL__InServer__Util, file);
Add plperl.on_plperl_init and plperl.on_plperlu_init settings for language-specific startup. Rename recently added plperl.on_perl_init to plperl.on_init. Also, code cleanup for utf8 hack. Patch from Tim Bunce, reviewed by Alex Hunsaker.
2010-02-12 20:35:25 +01:00
/* newXS for...::SPI::bootstrap is in select_perl_context() */
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
}
At 2005-05-21 20:18:50 +0530, ams@oryx.com wrote: > > > The second issue is where plperl returns a large result set. I have attached the following seven patches to address this problem: 1. Trivial. Replaces some errant spaces with tabs. 2. Trivial. Fixes the spelling of Jan's name, and gets rid of many inane, useless, annoying, and often misleading comments. Here's a sample: "plperl_init_all() - Initialize all". (I have tried to add some useful comments here and there, and will continue to do so now and again.) 3. Trivial. Splits up some long lines. 4. Converts SRFs in PL/Perl to use a Tuplestore and SFRM_Materialize to return the result set, based on the PL/PgSQL model. There are two major consequences: result sets will spill to disk when they can no longer fit in work_mem; and "select foo_srf()" no longer works. (I didn't lose sleep over the latter, since that form is not valid in PL/PgSQL, and it's not documented in PL/Perl.) 5. Trivial, but important. Fixes use of "undef" instead of undef. This would cause empty functions to fail in bizarre ways. I suspect that there's still another (old) bug here. I'll investigate further. 6. Moves the majority of (4) out into a new plperl_return_next() function, to make it possible to expose the functionality to Perl; cleans up some of the code besides. 7. Add an spi_return_next function for use in Perl code. If you want to apply the patches and try them out, 8-composite.diff is what you should use. (Note: my patches depend upon Andrew's use-strict and %_SHARED patches being applied.) Here's something to try: create or replace function foo() returns setof record as $$ $i = 0; for ("World", "PostgreSQL", "PL/Perl") { spi_return_next({f1=>++$i, f2=>'Hello', f3=>$_}); } return; $$ language plperl; select * from foo() as (f1 integer, f2 text, f3 text); (Many thanks to Andrews Dunstan and Supernews for their help.) Abhijit Menon-Sen
2005-06-04 22:33:06 +02:00
Fix multiple causes of breakage in plperl's error handling.
2003-04-20 23:15:34 +02:00
static SV *
First round of changes for new fmgr interface. fmgr itself and the key call sites are changed, but most called functions are still oldstyle. An exception is that the PL managers are updated (so, for example, NULL handling now behaves as expected in plperl and plpgsql functions). NOTE initdb is forced due to added column in pg_proc.
2000-05-28 19:56:29 +02:00
plperl_call_perl_func(plperl_proc_desc *desc, FunctionCallInfo fcinfo)
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
{
PL/Perl portability fix: avoid including XSUB.h in plperl.c. In Perl builds that define PERL_IMPLICIT_SYS, XSUB.h defines macros that replace a whole lot of basic libc functions with Perl functions. We can't tolerate that in plperl.c; it breaks at least PG_TRY and probably other stuff. The core idea of this patch is to include XSUB.h only in the .xs files where it's really needed, and to move any code broken by PERL_IMPLICIT_SYS out of the .xs files and into plperl.c. The reason this hasn't been a problem before is that our build techniques did not result in PERL_IMPLICIT_SYS appearing as a #define in PL/Perl, even on some platforms where Perl thinks it is defined. That's about to change in order to fix a nasty portability issue, so we need this work to make the code safe for that. Rather unaccountably, the Perl people chose XSUB.h as the place to provide the versions of the aTHX/aTHX_ macros that are needed by code that's not explicitly aware of the MULTIPLICITY API conventions. Hence, just removing XSUB.h from plperl.c fails miserably. But we can work around that by defining PERL_NO_GET_CONTEXT (which would make the relevant stanza of XSUB.h a no-op anyway). As explained in perlguts.pod, that means we need to add a "dTHX" macro call in every C function that calls a Perl API function. In most of them we just add this at the top; but since the macro fetches the current Perl interpreter pointer, more care is needed in functions that switch the active interpreter. Lack of the macro is easily recognized since it results in bleats about "my_perl" not being defined. (A nice side benefit of this is that it significantly reduces the number of fetches of the current interpreter pointer. On my machine, plperl.so gets more than 10% smaller, and there's probably some performance win too. We could reduce the number of fetches still more by decorating the code with pTHX_/aTHX_ macros to pass the interpreter pointer around, as explained by perlguts.pod; but that's a task for another day.) Formatting note: pgindent seems happy to treat "dTHX;" as a declaration so long as it's the first thing after the left brace, as we'd already observed with respect to the similar macro "dSP;". If you try to put it later in a set of declarations, pgindent puts ugly extra space around it. Having removed XSUB.h from plperl.c, we need only move the support functions for spi_return_next and util_elog (both of which use PG_TRY) out of the .xs files and into plperl.c. This seems sufficient to avoid the known problems caused by PERL_IMPLICIT_SYS, although we could move more code if additional issues emerge. This will need to be back-patched, but first let's see what the buildfarm makes of it. Patch by me, with some help from Ashutosh Sharma Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
2017-07-28 18:25:43 +02:00
dTHX;
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
dSP;
SV *retval;
int i;
int count;
Add transforms feature This provides a mechanism for specifying conversions between SQL data types and procedural languages. As examples, there are transforms for hstore and ltree for PL/Perl and PL/Python. reviews by Pavel Stěhule and Andres Freund
2015-04-26 16:33:14 +02:00
Oid *argtypes = NULL;
int nargs = 0;
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
ENTER;
SAVETMPS;
Fix multiple causes of breakage in plperl's error handling.
2003-04-20 23:15:34 +02:00
PUSHMARK(SP);
Set up PLPerl trigger data using C code instead of Perl code. This is an efficiency change, and means we now no longer have to run "out $_TD; local $_TD = shift;", which was especially pointless in the case of non-trigger functions where the passed value was always undef anyway. A tiny open issue is whether we should get rid of the $prolog argument of mkfunc, and the corresponding pushed value, which is now just a constant "false". Tim Bunce, reviewed by Alex Hunsaker.
2011-02-01 15:43:25 +01:00
EXTEND(sp, desc->nargs);
Further plperl cleanup: be more paranoid about checking the type of data returned from Perl. Consolidate multiple bits of code to convert a Perl hash to a tuple, and drive the conversion off the keys present in the hash rather than the tuple column names, so we detect error if the hash contains keys it shouldn't. (This means keys not in the hash will silently default to NULL, which seems ok to me.) Fix a bunch of reference-count leaks too.
2004-11-23 01:21:24 +01:00
Instruct Coverity using an assertion. This should make Coverity deduce that plperl_call_perl_func() does not dereference NULL argtypes. Back-patch to 9.5, where the affected code was introduced. Michael Paquier
2015-12-05 09:04:17 +01:00
/* Get signature for true functions; inline blocks have no args. */
Add transforms feature This provides a mechanism for specifying conversions between SQL data types and procedural languages. As examples, there are transforms for hstore and ltree for PL/Perl and PL/Python. reviews by Pavel Stěhule and Andres Freund
2015-04-26 16:33:14 +02:00
if (fcinfo->flinfo->fn_oid)
get_func_signature(fcinfo->flinfo->fn_oid, &argtypes, &nargs);
Instruct Coverity using an assertion. This should make Coverity deduce that plperl_call_perl_func() does not dereference NULL argtypes. Back-patch to 9.5, where the affected code was introduced. Michael Paquier
2015-12-05 09:04:17 +01:00
Assert(nargs == desc->nargs);
Add transforms feature This provides a mechanism for specifying conversions between SQL data types and procedural languages. As examples, there are transforms for hstore and ltree for PL/Perl and PL/Python. reviews by Pavel Stěhule and Andres Freund
2015-04-26 16:33:14 +02:00
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
for (i = 0; i < desc->nargs; i++)
{
Change function call information to be variable length. Before this change FunctionCallInfoData, the struct arguments etc for V1 function calls are stored in, always had space for FUNC_MAX_ARGS/100 arguments, storing datums and their nullness in two arrays. For nearly every function call 100 arguments is far more than needed, therefore wasting memory. Arg and argnull being two separate arrays also guarantees that to access a single argument, two cachelines have to be touched. Change the layout so there's a single variable-length array with pairs of value / isnull. That drastically reduces memory consumption for most function calls (on x86-64 a two argument function now uses 64bytes, previously 936 bytes), and makes it very likely that argument value and its nullness are on the same cacheline. Arguments are stored in a new NullableDatum struct, which, due to padding, needs more memory per argument than before. But as usually far fewer arguments are stored, and individual arguments are cheaper to access, that's still a clear win. It's likely that there's other places where conversion to NullableDatum arrays would make sense, e.g. TupleTableSlots, but that's for another commit. Because the function call information is now variable-length allocations have to take the number of arguments into account. For heap allocations that can be done with SizeForFunctionCallInfoData(), for on-stack allocations there's a new LOCAL_FCINFO(name, nargs) macro that helps to allocate an appropriately sized and aligned variable. Some places with stack allocation function call information don't know the number of arguments at compile time, and currently variably sized stack allocations aren't allowed in postgres. Therefore allow for FUNC_MAX_ARGS space in these cases. They're not that common, so for now that seems acceptable. Because of the need to allocate FunctionCallInfo of the appropriate size, older extensions may need to update their code. To avoid subtle breakages, the FunctionCallInfoData struct has been renamed to FunctionCallInfoBaseData. Most code only references FunctionCallInfo, so that shouldn't cause much collateral damage. This change is also a prerequisite for more efficient expression JIT compilation (by allocating the function call information on the stack, allowing LLVM to optimize it away); previously the size of the call information caused problems inside LLVM's optimizer. Author: Andres Freund Reviewed-By: Tom Lane Discussion: https://postgr.es/m/20180605172952.x34m5uz6ju6enaem@alap3.anarazel.de
2019-01-26 23:17:52 +01:00
if (fcinfo->args[i].isnull)
Various small improvements and cleanups for PL/Perl. - Allow (ineffective) use of 'require' in plperl If the required module is not already loaded then it dies. So "use strict;" now works in plperl. - Pre-load the feature module if perl >= 5.10. So "use feature :5.10;" now works in plperl. - Stored procedure subs are now given names. The names are not visible in ordinary use, but they make tools like Devel::NYTProf and Devel::Cover much more useful. - Simplified and generalized the subroutine creation code. Now one code path for generating sub source code, not four. Can generate multiple 'use' statements with specific imports (which handles plperl.use_strict currently and can easily be extended to handle a plperl.use_feature=':5.12' in future). - Disallows use of Safe version 2.20 which is broken for PL/Perl. http://rt.perl.org/rt3/Ticket/Display.html?id=72068 - Assorted minor optimizations by pre-growing data structures. Patch from Tim Bunce, reviewed by Alex Hunsaker.
2010-01-27 00:11:56 +01:00
PUSHs(&PL_sv_undef);
Fix memory clobber problem reported by John Hansen: plperl_safe_init() may expand the Perl stack, therefore we must SPAGAIN to reload the local stack pointer after calling it. Also a couple other marginal readability improvements.
2004-11-18 22:35:42 +01:00
else if (desc->arg_is_rowtype[i])
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
{
Change function call information to be variable length. Before this change FunctionCallInfoData, the struct arguments etc for V1 function calls are stored in, always had space for FUNC_MAX_ARGS/100 arguments, storing datums and their nullness in two arrays. For nearly every function call 100 arguments is far more than needed, therefore wasting memory. Arg and argnull being two separate arrays also guarantees that to access a single argument, two cachelines have to be touched. Change the layout so there's a single variable-length array with pairs of value / isnull. That drastically reduces memory consumption for most function calls (on x86-64 a two argument function now uses 64bytes, previously 936 bytes), and makes it very likely that argument value and its nullness are on the same cacheline. Arguments are stored in a new NullableDatum struct, which, due to padding, needs more memory per argument than before. But as usually far fewer arguments are stored, and individual arguments are cheaper to access, that's still a clear win. It's likely that there's other places where conversion to NullableDatum arrays would make sense, e.g. TupleTableSlots, but that's for another commit. Because the function call information is now variable-length allocations have to take the number of arguments into account. For heap allocations that can be done with SizeForFunctionCallInfoData(), for on-stack allocations there's a new LOCAL_FCINFO(name, nargs) macro that helps to allocate an appropriately sized and aligned variable. Some places with stack allocation function call information don't know the number of arguments at compile time, and currently variably sized stack allocations aren't allowed in postgres. Therefore allow for FUNC_MAX_ARGS space in these cases. They're not that common, so for now that seems acceptable. Because of the need to allocate FunctionCallInfo of the appropriate size, older extensions may need to update their code. To avoid subtle breakages, the FunctionCallInfoData struct has been renamed to FunctionCallInfoBaseData. Most code only references FunctionCallInfo, so that shouldn't cause much collateral damage. This change is also a prerequisite for more efficient expression JIT compilation (by allocating the function call information on the stack, allowing LLVM to optimize it away); previously the size of the call information caused problems inside LLVM's optimizer. Author: Andres Freund Reviewed-By: Tom Lane Discussion: https://postgr.es/m/20180605172952.x34m5uz6ju6enaem@alap3.anarazel.de
2019-01-26 23:17:52 +01:00
SV *sv = plperl_hash_from_datum(fcinfo->args[i].value);
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
PUSHs(sv_2mortal(sv));
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
}
else
{
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
SV *sv;
Add transforms feature This provides a mechanism for specifying conversions between SQL data types and procedural languages. As examples, there are transforms for hstore and ltree for PL/Perl and PL/Python. reviews by Pavel Stěhule and Andres Freund
2015-04-26 16:33:14 +02:00
Oid funcid;
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
if (OidIsValid(desc->arg_arraytype[i]))
Change function call information to be variable length. Before this change FunctionCallInfoData, the struct arguments etc for V1 function calls are stored in, always had space for FUNC_MAX_ARGS/100 arguments, storing datums and their nullness in two arrays. For nearly every function call 100 arguments is far more than needed, therefore wasting memory. Arg and argnull being two separate arrays also guarantees that to access a single argument, two cachelines have to be touched. Change the layout so there's a single variable-length array with pairs of value / isnull. That drastically reduces memory consumption for most function calls (on x86-64 a two argument function now uses 64bytes, previously 936 bytes), and makes it very likely that argument value and its nullness are on the same cacheline. Arguments are stored in a new NullableDatum struct, which, due to padding, needs more memory per argument than before. But as usually far fewer arguments are stored, and individual arguments are cheaper to access, that's still a clear win. It's likely that there's other places where conversion to NullableDatum arrays would make sense, e.g. TupleTableSlots, but that's for another commit. Because the function call information is now variable-length allocations have to take the number of arguments into account. For heap allocations that can be done with SizeForFunctionCallInfoData(), for on-stack allocations there's a new LOCAL_FCINFO(name, nargs) macro that helps to allocate an appropriately sized and aligned variable. Some places with stack allocation function call information don't know the number of arguments at compile time, and currently variably sized stack allocations aren't allowed in postgres. Therefore allow for FUNC_MAX_ARGS space in these cases. They're not that common, so for now that seems acceptable. Because of the need to allocate FunctionCallInfo of the appropriate size, older extensions may need to update their code. To avoid subtle breakages, the FunctionCallInfoData struct has been renamed to FunctionCallInfoBaseData. Most code only references FunctionCallInfo, so that shouldn't cause much collateral damage. This change is also a prerequisite for more efficient expression JIT compilation (by allocating the function call information on the stack, allowing LLVM to optimize it away); previously the size of the call information caused problems inside LLVM's optimizer. Author: Andres Freund Reviewed-By: Tom Lane Discussion: https://postgr.es/m/20180605172952.x34m5uz6ju6enaem@alap3.anarazel.de
2019-01-26 23:17:52 +01:00
sv = plperl_ref_from_pg_array(fcinfo->args[i].value, desc->arg_arraytype[i]);
Add transforms feature This provides a mechanism for specifying conversions between SQL data types and procedural languages. As examples, there are transforms for hstore and ltree for PL/Perl and PL/Python. reviews by Pavel Stěhule and Andres Freund
2015-04-26 16:33:14 +02:00
else if ((funcid = get_transform_fromsql(argtypes[i], current_call_data->prodesc->lang_oid, current_call_data->prodesc->trftypes)))
Change function call information to be variable length. Before this change FunctionCallInfoData, the struct arguments etc for V1 function calls are stored in, always had space for FUNC_MAX_ARGS/100 arguments, storing datums and their nullness in two arrays. For nearly every function call 100 arguments is far more than needed, therefore wasting memory. Arg and argnull being two separate arrays also guarantees that to access a single argument, two cachelines have to be touched. Change the layout so there's a single variable-length array with pairs of value / isnull. That drastically reduces memory consumption for most function calls (on x86-64 a two argument function now uses 64bytes, previously 936 bytes), and makes it very likely that argument value and its nullness are on the same cacheline. Arguments are stored in a new NullableDatum struct, which, due to padding, needs more memory per argument than before. But as usually far fewer arguments are stored, and individual arguments are cheaper to access, that's still a clear win. It's likely that there's other places where conversion to NullableDatum arrays would make sense, e.g. TupleTableSlots, but that's for another commit. Because the function call information is now variable-length allocations have to take the number of arguments into account. For heap allocations that can be done with SizeForFunctionCallInfoData(), for on-stack allocations there's a new LOCAL_FCINFO(name, nargs) macro that helps to allocate an appropriately sized and aligned variable. Some places with stack allocation function call information don't know the number of arguments at compile time, and currently variably sized stack allocations aren't allowed in postgres. Therefore allow for FUNC_MAX_ARGS space in these cases. They're not that common, so for now that seems acceptable. Because of the need to allocate FunctionCallInfo of the appropriate size, older extensions may need to update their code. To avoid subtle breakages, the FunctionCallInfoData struct has been renamed to FunctionCallInfoBaseData. Most code only references FunctionCallInfo, so that shouldn't cause much collateral damage. This change is also a prerequisite for more efficient expression JIT compilation (by allocating the function call information on the stack, allowing LLVM to optimize it away); previously the size of the call information caused problems inside LLVM's optimizer. Author: Andres Freund Reviewed-By: Tom Lane Discussion: https://postgr.es/m/20180605172952.x34m5uz6ju6enaem@alap3.anarazel.de
2019-01-26 23:17:52 +01:00
sv = (SV *) DatumGetPointer(OidFunctionCall1(funcid, fcinfo->args[i].value));
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
else
{
char *tmp;
tmp = OutputFunctionCall(&(desc->arg_out_func[i]),
Change function call information to be variable length. Before this change FunctionCallInfoData, the struct arguments etc for V1 function calls are stored in, always had space for FUNC_MAX_ARGS/100 arguments, storing datums and their nullness in two arrays. For nearly every function call 100 arguments is far more than needed, therefore wasting memory. Arg and argnull being two separate arrays also guarantees that to access a single argument, two cachelines have to be touched. Change the layout so there's a single variable-length array with pairs of value / isnull. That drastically reduces memory consumption for most function calls (on x86-64 a two argument function now uses 64bytes, previously 936 bytes), and makes it very likely that argument value and its nullness are on the same cacheline. Arguments are stored in a new NullableDatum struct, which, due to padding, needs more memory per argument than before. But as usually far fewer arguments are stored, and individual arguments are cheaper to access, that's still a clear win. It's likely that there's other places where conversion to NullableDatum arrays would make sense, e.g. TupleTableSlots, but that's for another commit. Because the function call information is now variable-length allocations have to take the number of arguments into account. For heap allocations that can be done with SizeForFunctionCallInfoData(), for on-stack allocations there's a new LOCAL_FCINFO(name, nargs) macro that helps to allocate an appropriately sized and aligned variable. Some places with stack allocation function call information don't know the number of arguments at compile time, and currently variably sized stack allocations aren't allowed in postgres. Therefore allow for FUNC_MAX_ARGS space in these cases. They're not that common, so for now that seems acceptable. Because of the need to allocate FunctionCallInfo of the appropriate size, older extensions may need to update their code. To avoid subtle breakages, the FunctionCallInfoData struct has been renamed to FunctionCallInfoBaseData. Most code only references FunctionCallInfo, so that shouldn't cause much collateral damage. This change is also a prerequisite for more efficient expression JIT compilation (by allocating the function call information on the stack, allowing LLVM to optimize it away); previously the size of the call information caused problems inside LLVM's optimizer. Author: Andres Freund Reviewed-By: Tom Lane Discussion: https://postgr.es/m/20180605172952.x34m5uz6ju6enaem@alap3.anarazel.de
2019-01-26 23:17:52 +01:00
fcinfo->args[i].value);
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
sv = cstr2sv(tmp);
pfree(tmp);
}
Fix memory clobber problem reported by John Hansen: plperl_safe_init() may expand the Perl stack, therefore we must SPAGAIN to reload the local stack pointer after calling it. Also a couple other marginal readability improvements.
2004-11-18 22:35:42 +01:00
Various small improvements and cleanups for PL/Perl. - Allow (ineffective) use of 'require' in plperl If the required module is not already loaded then it dies. So "use strict;" now works in plperl. - Pre-load the feature module if perl >= 5.10. So "use feature :5.10;" now works in plperl. - Stored procedure subs are now given names. The names are not visible in ordinary use, but they make tools like Devel::NYTProf and Devel::Cover much more useful. - Simplified and generalized the subroutine creation code. Now one code path for generating sub source code, not four. Can generate multiple 'use' statements with specific imports (which handles plperl.use_strict currently and can easily be extended to handle a plperl.use_feature=':5.12' in future). - Disallows use of Safe version 2.20 which is broken for PL/Perl. http://rt.perl.org/rt3/Ticket/Display.html?id=72068 - Assorted minor optimizations by pre-growing data structures. Patch from Tim Bunce, reviewed by Alex Hunsaker.
2010-01-27 00:11:56 +01:00
PUSHs(sv_2mortal(sv));
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
}
}
PUTBACK;
Fix multiple causes of breakage in plperl's error handling.
2003-04-20 23:15:34 +02:00
/* Do NOT use G_KEEPERR here */
plperl: update ppport.h to Perl 5.34.0. Also apply the changes suggested by running perl ppport.h --compat-version=5.8.0 And remove some no-longer-required NEED_foo declarations. Dagfinn Ilmari Mannsåker Discussion: https://postgr.es/m/87y278s6iq.fsf@wibble.ilmari.org
2021-10-07 19:59:43 +02:00
count = call_sv(desc->reference, G_SCALAR | G_EVAL);
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
SPAGAIN;
if (count != 1)
{
PUTBACK;
FREETMPS;
LEAVE;
Fix a number of places that produced XX000 errors in the regression tests. It's against project policy to use elog() for user-facing errors, or to omit an errcode() selection for errors that aren't supposed to be "can't happen" cases. Fix all the violations of this policy that result in ERRCODE_INTERNAL_ERROR log entries during the standard regression tests, as errors that can reliably be triggered from SQL surely should be considered user-facing. I also looked through all the files touched by this commit and fixed other nearby problems of the same ilk. I do not claim to have fixed all violations of the policy, just the ones in these files. In a few places I also changed existing ERRCODE choices that didn't seem particularly appropriate; mainly replacing ERRCODE_SYNTAX_ERROR by something more specific. Back-patch to 9.5, but no further; changing ERRCODE assignments in stable branches doesn't seem like a good idea.
2015-08-03 05:49:19 +02:00
ereport(ERROR,
(errcode(ERRCODE_EXTERNAL_ROUTINE_EXCEPTION),
errmsg("didn't get a return item from function")));
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
}
This patch, when applied in src/pl will unbreak plperl in 7.0.2 release. Sorry, if that's fixed ages ago - I don't track development versions of PostgreSQL. Patch is just a little bit tested (some valid functions created and successfully run as well as some erroneous ones created and emitted proper error messages when used). My platform is FreeBSD 5.0-CURRENT (with perl 5.6.0 provided in the base system). Alex Kapranoff
2000-09-12 06:28:30 +02:00
if (SvTRUE(ERRSV))
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
{
Remove ill-considered suppression of gcc warnings in plperl, and fix some of the bugs exposed thereby. The remaining 'might be used uninitialized' warnings look like live bugs, but I am not familiar enough with Perl/C hacking to tell how to fix them.
2004-11-17 22:23:36 +01:00
(void) POPs;
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
PUTBACK;
FREETMPS;
LEAVE;
Fix a number of places that produced XX000 errors in the regression tests. It's against project policy to use elog() for user-facing errors, or to omit an errcode() selection for errors that aren't supposed to be "can't happen" cases. Fix all the violations of this policy that result in ERRCODE_INTERNAL_ERROR log entries during the standard regression tests, as errors that can reliably be triggered from SQL surely should be considered user-facing. I also looked through all the files touched by this commit and fixed other nearby problems of the same ilk. I do not claim to have fixed all violations of the policy, just the ones in these files. In a few places I also changed existing ERRCODE choices that didn't seem particularly appropriate; mainly replacing ERRCODE_SYNTAX_ERROR by something more specific. Back-patch to 9.5, but no further; changing ERRCODE assignments in stable branches doesn't seem like a good idea.
2015-08-03 05:49:19 +02:00
/* XXX need to find a way to determine a better errcode here */
Update plperl to use ereport() not elog() for user-facing messages, so that they will be translatable. Give messages some semblance of conformance to the style guide.
2004-11-29 21:11:06 +01:00
ereport(ERROR,
Fix a number of places that produced XX000 errors in the regression tests. It's against project policy to use elog() for user-facing errors, or to omit an errcode() selection for errors that aren't supposed to be "can't happen" cases. Fix all the violations of this policy that result in ERRCODE_INTERNAL_ERROR log entries during the standard regression tests, as errors that can reliably be triggered from SQL surely should be considered user-facing. I also looked through all the files touched by this commit and fixed other nearby problems of the same ilk. I do not claim to have fixed all violations of the policy, just the ones in these files. In a few places I also changed existing ERRCODE choices that didn't seem particularly appropriate; mainly replacing ERRCODE_SYNTAX_ERROR by something more specific. Back-patch to 9.5, but no further; changing ERRCODE assignments in stable branches doesn't seem like a good idea.
2015-08-03 05:49:19 +02:00
(errcode(ERRCODE_EXTERNAL_ROUTINE_EXCEPTION),
errmsg("%s", strip_trailing_ws(sv2cstr(ERRSV)))));
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
}
retval = newSVsv(POPs);
PUTBACK;
FREETMPS;
LEAVE;
return retval;
}
At 2005-05-21 20:18:50 +0530, ams@oryx.com wrote: > > > The second issue is where plperl returns a large result set. I have attached the following seven patches to address this problem: 1. Trivial. Replaces some errant spaces with tabs. 2. Trivial. Fixes the spelling of Jan's name, and gets rid of many inane, useless, annoying, and often misleading comments. Here's a sample: "plperl_init_all() - Initialize all". (I have tried to add some useful comments here and there, and will continue to do so now and again.) 3. Trivial. Splits up some long lines. 4. Converts SRFs in PL/Perl to use a Tuplestore and SFRM_Materialize to return the result set, based on the PL/PgSQL model. There are two major consequences: result sets will spill to disk when they can no longer fit in work_mem; and "select foo_srf()" no longer works. (I didn't lose sleep over the latter, since that form is not valid in PL/PgSQL, and it's not documented in PL/Perl.) 5. Trivial, but important. Fixes use of "undef" instead of undef. This would cause empty functions to fail in bizarre ways. I suspect that there's still another (old) bug here. I'll investigate further. 6. Moves the majority of (4) out into a new plperl_return_next() function, to make it possible to expose the functionality to Perl; cleans up some of the code besides. 7. Add an spi_return_next function for use in Perl code. If you want to apply the patches and try them out, 8-composite.diff is what you should use. (Note: my patches depend upon Andrew's use-strict and %_SHARED patches being applied.) Here's something to try: create or replace function foo() returns setof record as $$ $i = 0; for ("World", "PostgreSQL", "PL/Perl") { spi_return_next({f1=>++$i, f2=>'Hello', f3=>$_}); } return; $$ language plperl; select * from foo() as (f1 integer, f2 text, f3 text); (Many thanks to Andrews Dunstan and Supernews for their help.) Abhijit Menon-Sen
2005-06-04 22:33:06 +02:00
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
static SV *
Further plperl cleanup: be more paranoid about checking the type of data returned from Perl. Consolidate multiple bits of code to convert a Perl hash to a tuple, and drive the conversion off the keys present in the hash rather than the tuple column names, so we detect error if the hash contains keys it shouldn't. (This means keys not in the hash will silently default to NULL, which seems ok to me.) Fix a bunch of reference-count leaks too.
2004-11-23 01:21:24 +01:00
plperl_call_perl_trigger_func(plperl_proc_desc *desc, FunctionCallInfo fcinfo,
SV *td)
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
{
PL/Perl portability fix: avoid including XSUB.h in plperl.c. In Perl builds that define PERL_IMPLICIT_SYS, XSUB.h defines macros that replace a whole lot of basic libc functions with Perl functions. We can't tolerate that in plperl.c; it breaks at least PG_TRY and probably other stuff. The core idea of this patch is to include XSUB.h only in the .xs files where it's really needed, and to move any code broken by PERL_IMPLICIT_SYS out of the .xs files and into plperl.c. The reason this hasn't been a problem before is that our build techniques did not result in PERL_IMPLICIT_SYS appearing as a #define in PL/Perl, even on some platforms where Perl thinks it is defined. That's about to change in order to fix a nasty portability issue, so we need this work to make the code safe for that. Rather unaccountably, the Perl people chose XSUB.h as the place to provide the versions of the aTHX/aTHX_ macros that are needed by code that's not explicitly aware of the MULTIPLICITY API conventions. Hence, just removing XSUB.h from plperl.c fails miserably. But we can work around that by defining PERL_NO_GET_CONTEXT (which would make the relevant stanza of XSUB.h a no-op anyway). As explained in perlguts.pod, that means we need to add a "dTHX" macro call in every C function that calls a Perl API function. In most of them we just add this at the top; but since the macro fetches the current Perl interpreter pointer, more care is needed in functions that switch the active interpreter. Lack of the macro is easily recognized since it results in bleats about "my_perl" not being defined. (A nice side benefit of this is that it significantly reduces the number of fetches of the current interpreter pointer. On my machine, plperl.so gets more than 10% smaller, and there's probably some performance win too. We could reduce the number of fetches still more by decorating the code with pTHX_/aTHX_ macros to pass the interpreter pointer around, as explained by perlguts.pod; but that's a task for another day.) Formatting note: pgindent seems happy to treat "dTHX;" as a declaration so long as it's the first thing after the left brace, as we'd already observed with respect to the similar macro "dSP;". If you try to put it later in a set of declarations, pgindent puts ugly extra space around it. Having removed XSUB.h from plperl.c, we need only move the support functions for spi_return_next and util_elog (both of which use PG_TRY) out of the .xs files and into plperl.c. This seems sufficient to avoid the known problems caused by PERL_IMPLICIT_SYS, although we could move more code if additional issues emerge. This will need to be back-patched, but first let's see what the buildfarm makes of it. Patch by me, with some help from Ashutosh Sharma Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
2017-07-28 18:25:43 +02:00
dTHX;
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
dSP;
pgindent run on plperl.c
2011-02-17 20:40:13 +01:00
SV *retval,
*TDsv;
int i,
count;
Set up PLPerl trigger data using C code instead of Perl code. This is an efficiency change, and means we now no longer have to run "out $_TD; local $_TD = shift;", which was especially pointless in the case of non-trigger functions where the passed value was always undef anyway. A tiny open issue is whether we should get rid of the $prolog argument of mkfunc, and the corresponding pushed value, which is now just a constant "false". Tim Bunce, reviewed by Alex Hunsaker.
2011-02-01 15:43:25 +01:00
Trigger *tg_trigger = ((TriggerData *) fcinfo->context)->tg_trigger;
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
ENTER;
SAVETMPS;
plperl: Package-qualify _TD Failing to do so causes trigger invocation to fail when they are nested within a function invocation that changes the current package. Backpatch to 9.1; previous releases used a different method to obtain _TD. Per bug report from Mark Murawski (bug #6511) Author: Alex Hunsaker
2012-03-19 21:29:05 +01:00
TDsv = get_sv("main::_TD", 0);
Fix declaration of $_TD in "strict" trigger functions This was broken in commit ef19dc6d39dd2490ff61489da55d95d6941140bf by the Bunce/Hunsaker/Dunstan team, which moved the declaration from plperl_create_sub to plperl_call_perl_trigger_func. This doesn't actually work because the validator code would not find the variable declared; and even if you manage to get past the validator, it still doesn't work because get_sv("_TD", GV_ADD) doesn't have the expected effect. The only reason this got beyond testing is that it only fails in strict mode. We need to declare it as a global just like %_SHARED; it is simpler than trying to actually do what the patch initially intended, and is said to have the same performance benefit. As a more serious issue, fix $_TD not being properly local()ized, meaning nested trigger functions would clobber $_TD. Alex Hunsaker, per test report from Greg Mullane
2011-05-19 05:56:18 +02:00
if (!TDsv)
Fix a number of places that produced XX000 errors in the regression tests. It's against project policy to use elog() for user-facing errors, or to omit an errcode() selection for errors that aren't supposed to be "can't happen" cases. Fix all the violations of this policy that result in ERRCODE_INTERNAL_ERROR log entries during the standard regression tests, as errors that can reliably be triggered from SQL surely should be considered user-facing. I also looked through all the files touched by this commit and fixed other nearby problems of the same ilk. I do not claim to have fixed all violations of the policy, just the ones in these files. In a few places I also changed existing ERRCODE choices that didn't seem particularly appropriate; mainly replacing ERRCODE_SYNTAX_ERROR by something more specific. Back-patch to 9.5, but no further; changing ERRCODE assignments in stable branches doesn't seem like a good idea.
2015-08-03 05:49:19 +02:00
ereport(ERROR,
(errcode(ERRCODE_EXTERNAL_ROUTINE_EXCEPTION),
errmsg("couldn't fetch $_TD")));
Fix declaration of $_TD in "strict" trigger functions This was broken in commit ef19dc6d39dd2490ff61489da55d95d6941140bf by the Bunce/Hunsaker/Dunstan team, which moved the declaration from plperl_create_sub to plperl_call_perl_trigger_func. This doesn't actually work because the validator code would not find the variable declared; and even if you manage to get past the validator, it still doesn't work because get_sv("_TD", GV_ADD) doesn't have the expected effect. The only reason this got beyond testing is that it only fails in strict mode. We need to declare it as a global just like %_SHARED; it is simpler than trying to actually do what the patch initially intended, and is said to have the same performance benefit. As a more serious issue, fix $_TD not being properly local()ized, meaning nested trigger functions would clobber $_TD. Alex Hunsaker, per test report from Greg Mullane
2011-05-19 05:56:18 +02:00
save_item(TDsv); /* local $_TD */
Set up PLPerl trigger data using C code instead of Perl code. This is an efficiency change, and means we now no longer have to run "out $_TD; local $_TD = shift;", which was especially pointless in the case of non-trigger functions where the passed value was always undef anyway. A tiny open issue is whether we should get rid of the $prolog argument of mkfunc, and the corresponding pushed value, which is now just a constant "false". Tim Bunce, reviewed by Alex Hunsaker.
2011-02-01 15:43:25 +01:00
sv_setsv(TDsv, td);
Further plperl cleanup: be more paranoid about checking the type of data returned from Perl. Consolidate multiple bits of code to convert a Perl hash to a tuple, and drive the conversion off the keys present in the hash rather than the tuple column names, so we detect error if the hash contains keys it shouldn't. (This means keys not in the hash will silently default to NULL, which seems ok to me.) Fix a bunch of reference-count leaks too.
2004-11-23 01:21:24 +01:00
Set up PLPerl trigger data using C code instead of Perl code. This is an efficiency change, and means we now no longer have to run "out $_TD; local $_TD = shift;", which was especially pointless in the case of non-trigger functions where the passed value was always undef anyway. A tiny open issue is whether we should get rid of the $prolog argument of mkfunc, and the corresponding pushed value, which is now just a constant "false". Tim Bunce, reviewed by Alex Hunsaker.
2011-02-01 15:43:25 +01:00
PUSHMARK(sp);
EXTEND(sp, tg_trigger->tgnargs);
Further plperl cleanup: be more paranoid about checking the type of data returned from Perl. Consolidate multiple bits of code to convert a Perl hash to a tuple, and drive the conversion off the keys present in the hash rather than the tuple column names, so we detect error if the hash contains keys it shouldn't. (This means keys not in the hash will silently default to NULL, which seems ok to me.) Fix a bunch of reference-count leaks too.
2004-11-23 01:21:24 +01:00
Fix memory clobber problem reported by John Hansen: plperl_safe_init() may expand the Perl stack, therefore we must SPAGAIN to reload the local stack pointer after calling it. Also a couple other marginal readability improvements.
2004-11-18 22:35:42 +01:00
for (i = 0; i < tg_trigger->tgnargs; i++)
Force strings passed to and from plperl to be in UTF8 encoding. String are converted to UTF8 on the way into perl and to the database encoding on the way back. This avoids a number of observed anomalies, and ensures Perl a consistent view of the world. Some minor code cleanups are also accomplished. Alex Hunsaker, reviewed by Andy Colson.
2011-02-06 23:29:26 +01:00
PUSHs(sv_2mortal(cstr2sv(tg_trigger->tgargs[i])));
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
PUTBACK;
Further plperl cleanup: be more paranoid about checking the type of data returned from Perl. Consolidate multiple bits of code to convert a Perl hash to a tuple, and drive the conversion off the keys present in the hash rather than the tuple column names, so we detect error if the hash contains keys it shouldn't. (This means keys not in the hash will silently default to NULL, which seems ok to me.) Fix a bunch of reference-count leaks too.
2004-11-23 01:21:24 +01:00
/* Do NOT use G_KEEPERR here */
plperl: update ppport.h to Perl 5.34.0. Also apply the changes suggested by running perl ppport.h --compat-version=5.8.0 And remove some no-longer-required NEED_foo declarations. Dagfinn Ilmari Mannsåker Discussion: https://postgr.es/m/87y278s6iq.fsf@wibble.ilmari.org
2021-10-07 19:59:43 +02:00
count = call_sv(desc->reference, G_SCALAR | G_EVAL);
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
SPAGAIN;
if (count != 1)
{
PUTBACK;
FREETMPS;
LEAVE;
Fix a number of places that produced XX000 errors in the regression tests. It's against project policy to use elog() for user-facing errors, or to omit an errcode() selection for errors that aren't supposed to be "can't happen" cases. Fix all the violations of this policy that result in ERRCODE_INTERNAL_ERROR log entries during the standard regression tests, as errors that can reliably be triggered from SQL surely should be considered user-facing. I also looked through all the files touched by this commit and fixed other nearby problems of the same ilk. I do not claim to have fixed all violations of the policy, just the ones in these files. In a few places I also changed existing ERRCODE choices that didn't seem particularly appropriate; mainly replacing ERRCODE_SYNTAX_ERROR by something more specific. Back-patch to 9.5, but no further; changing ERRCODE assignments in stable branches doesn't seem like a good idea.
2015-08-03 05:49:19 +02:00
ereport(ERROR,
(errcode(ERRCODE_EXTERNAL_ROUTINE_EXCEPTION),
errmsg("didn't get a return item from trigger function")));
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
}
if (SvTRUE(ERRSV))
{
Remove ill-considered suppression of gcc warnings in plperl, and fix some of the bugs exposed thereby. The remaining 'might be used uninitialized' warnings look like live bugs, but I am not familiar enough with Perl/C hacking to tell how to fix them.
2004-11-17 22:23:36 +01:00
(void) POPs;
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
PUTBACK;
FREETMPS;
LEAVE;
Fix a number of places that produced XX000 errors in the regression tests. It's against project policy to use elog() for user-facing errors, or to omit an errcode() selection for errors that aren't supposed to be "can't happen" cases. Fix all the violations of this policy that result in ERRCODE_INTERNAL_ERROR log entries during the standard regression tests, as errors that can reliably be triggered from SQL surely should be considered user-facing. I also looked through all the files touched by this commit and fixed other nearby problems of the same ilk. I do not claim to have fixed all violations of the policy, just the ones in these files. In a few places I also changed existing ERRCODE choices that didn't seem particularly appropriate; mainly replacing ERRCODE_SYNTAX_ERROR by something more specific. Back-patch to 9.5, but no further; changing ERRCODE assignments in stable branches doesn't seem like a good idea.
2015-08-03 05:49:19 +02:00
/* XXX need to find a way to determine a better errcode here */
Update plperl to use ereport() not elog() for user-facing messages, so that they will be translatable. Give messages some semblance of conformance to the style guide.
2004-11-29 21:11:06 +01:00
ereport(ERROR,
Fix a number of places that produced XX000 errors in the regression tests. It's against project policy to use elog() for user-facing errors, or to omit an errcode() selection for errors that aren't supposed to be "can't happen" cases. Fix all the violations of this policy that result in ERRCODE_INTERNAL_ERROR log entries during the standard regression tests, as errors that can reliably be triggered from SQL surely should be considered user-facing. I also looked through all the files touched by this commit and fixed other nearby problems of the same ilk. I do not claim to have fixed all violations of the policy, just the ones in these files. In a few places I also changed existing ERRCODE choices that didn't seem particularly appropriate; mainly replacing ERRCODE_SYNTAX_ERROR by something more specific. Back-patch to 9.5, but no further; changing ERRCODE assignments in stable branches doesn't seem like a good idea.
2015-08-03 05:49:19 +02:00
(errcode(ERRCODE_EXTERNAL_ROUTINE_EXCEPTION),
errmsg("%s", strip_trailing_ws(sv2cstr(ERRSV)))));
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
}
retval = newSVsv(POPs);
PUTBACK;
FREETMPS;
LEAVE;
return retval;
}
Fix multiple causes of breakage in plperl's error handling.
2003-04-20 23:15:34 +02:00
At 2005-05-21 20:18:50 +0530, ams@oryx.com wrote: > > > The second issue is where plperl returns a large result set. I have attached the following seven patches to address this problem: 1. Trivial. Replaces some errant spaces with tabs. 2. Trivial. Fixes the spelling of Jan's name, and gets rid of many inane, useless, annoying, and often misleading comments. Here's a sample: "plperl_init_all() - Initialize all". (I have tried to add some useful comments here and there, and will continue to do so now and again.) 3. Trivial. Splits up some long lines. 4. Converts SRFs in PL/Perl to use a Tuplestore and SFRM_Materialize to return the result set, based on the PL/PgSQL model. There are two major consequences: result sets will spill to disk when they can no longer fit in work_mem; and "select foo_srf()" no longer works. (I didn't lose sleep over the latter, since that form is not valid in PL/PgSQL, and it's not documented in PL/Perl.) 5. Trivial, but important. Fixes use of "undef" instead of undef. This would cause empty functions to fail in bizarre ways. I suspect that there's still another (old) bug here. I'll investigate further. 6. Moves the majority of (4) out into a new plperl_return_next() function, to make it possible to expose the functionality to Perl; cleans up some of the code besides. 7. Add an spi_return_next function for use in Perl code. If you want to apply the patches and try them out, 8-composite.diff is what you should use. (Note: my patches depend upon Andrew's use-strict and %_SHARED patches being applied.) Here's something to try: create or replace function foo() returns setof record as $$ $i = 0; for ("World", "PostgreSQL", "PL/Perl") { spi_return_next({f1=>++$i, f2=>'Hello', f3=>$_}); } return; $$ language plperl; select * from foo() as (f1 integer, f2 text, f3 text); (Many thanks to Andrews Dunstan and Supernews for their help.) Abhijit Menon-Sen
2005-06-04 22:33:06 +02:00
PL/Perl: Add event trigger support From: Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2013-12-11 14:11:59 +01:00
static void
plperl_call_perl_event_trigger_func(plperl_proc_desc *desc,
FunctionCallInfo fcinfo,
SV *td)
{
PL/Perl portability fix: avoid including XSUB.h in plperl.c. In Perl builds that define PERL_IMPLICIT_SYS, XSUB.h defines macros that replace a whole lot of basic libc functions with Perl functions. We can't tolerate that in plperl.c; it breaks at least PG_TRY and probably other stuff. The core idea of this patch is to include XSUB.h only in the .xs files where it's really needed, and to move any code broken by PERL_IMPLICIT_SYS out of the .xs files and into plperl.c. The reason this hasn't been a problem before is that our build techniques did not result in PERL_IMPLICIT_SYS appearing as a #define in PL/Perl, even on some platforms where Perl thinks it is defined. That's about to change in order to fix a nasty portability issue, so we need this work to make the code safe for that. Rather unaccountably, the Perl people chose XSUB.h as the place to provide the versions of the aTHX/aTHX_ macros that are needed by code that's not explicitly aware of the MULTIPLICITY API conventions. Hence, just removing XSUB.h from plperl.c fails miserably. But we can work around that by defining PERL_NO_GET_CONTEXT (which would make the relevant stanza of XSUB.h a no-op anyway). As explained in perlguts.pod, that means we need to add a "dTHX" macro call in every C function that calls a Perl API function. In most of them we just add this at the top; but since the macro fetches the current Perl interpreter pointer, more care is needed in functions that switch the active interpreter. Lack of the macro is easily recognized since it results in bleats about "my_perl" not being defined. (A nice side benefit of this is that it significantly reduces the number of fetches of the current interpreter pointer. On my machine, plperl.so gets more than 10% smaller, and there's probably some performance win too. We could reduce the number of fetches still more by decorating the code with pTHX_/aTHX_ macros to pass the interpreter pointer around, as explained by perlguts.pod; but that's a task for another day.) Formatting note: pgindent seems happy to treat "dTHX;" as a declaration so long as it's the first thing after the left brace, as we'd already observed with respect to the similar macro "dSP;". If you try to put it later in a set of declarations, pgindent puts ugly extra space around it. Having removed XSUB.h from plperl.c, we need only move the support functions for spi_return_next and util_elog (both of which use PG_TRY) out of the .xs files and into plperl.c. This seems sufficient to avoid the known problems caused by PERL_IMPLICIT_SYS, although we could move more code if additional issues emerge. This will need to be back-patched, but first let's see what the buildfarm makes of it. Patch by me, with some help from Ashutosh Sharma Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
2017-07-28 18:25:43 +02:00
dTHX;
PL/Perl: Add event trigger support From: Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2013-12-11 14:11:59 +01:00
dSP;
SV *retval,
*TDsv;
int count;
ENTER;
SAVETMPS;
TDsv = get_sv("main::_TD", 0);
if (!TDsv)
Fix a number of places that produced XX000 errors in the regression tests. It's against project policy to use elog() for user-facing errors, or to omit an errcode() selection for errors that aren't supposed to be "can't happen" cases. Fix all the violations of this policy that result in ERRCODE_INTERNAL_ERROR log entries during the standard regression tests, as errors that can reliably be triggered from SQL surely should be considered user-facing. I also looked through all the files touched by this commit and fixed other nearby problems of the same ilk. I do not claim to have fixed all violations of the policy, just the ones in these files. In a few places I also changed existing ERRCODE choices that didn't seem particularly appropriate; mainly replacing ERRCODE_SYNTAX_ERROR by something more specific. Back-patch to 9.5, but no further; changing ERRCODE assignments in stable branches doesn't seem like a good idea.
2015-08-03 05:49:19 +02:00
ereport(ERROR,
(errcode(ERRCODE_EXTERNAL_ROUTINE_EXCEPTION),
errmsg("couldn't fetch $_TD")));
PL/Perl: Add event trigger support From: Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2013-12-11 14:11:59 +01:00
save_item(TDsv); /* local $_TD */
sv_setsv(TDsv, td);
PUSHMARK(sp);
PUTBACK;
/* Do NOT use G_KEEPERR here */
plperl: update ppport.h to Perl 5.34.0. Also apply the changes suggested by running perl ppport.h --compat-version=5.8.0 And remove some no-longer-required NEED_foo declarations. Dagfinn Ilmari Mannsåker Discussion: https://postgr.es/m/87y278s6iq.fsf@wibble.ilmari.org
2021-10-07 19:59:43 +02:00
count = call_sv(desc->reference, G_SCALAR | G_EVAL);
PL/Perl: Add event trigger support From: Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2013-12-11 14:11:59 +01:00
SPAGAIN;
if (count != 1)
{
PUTBACK;
FREETMPS;
LEAVE;
Fix a number of places that produced XX000 errors in the regression tests. It's against project policy to use elog() for user-facing errors, or to omit an errcode() selection for errors that aren't supposed to be "can't happen" cases. Fix all the violations of this policy that result in ERRCODE_INTERNAL_ERROR log entries during the standard regression tests, as errors that can reliably be triggered from SQL surely should be considered user-facing. I also looked through all the files touched by this commit and fixed other nearby problems of the same ilk. I do not claim to have fixed all violations of the policy, just the ones in these files. In a few places I also changed existing ERRCODE choices that didn't seem particularly appropriate; mainly replacing ERRCODE_SYNTAX_ERROR by something more specific. Back-patch to 9.5, but no further; changing ERRCODE assignments in stable branches doesn't seem like a good idea.
2015-08-03 05:49:19 +02:00
ereport(ERROR,
(errcode(ERRCODE_EXTERNAL_ROUTINE_EXCEPTION),
errmsg("didn't get a return item from trigger function")));
PL/Perl: Add event trigger support From: Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2013-12-11 14:11:59 +01:00
}
if (SvTRUE(ERRSV))
{
(void) POPs;
PUTBACK;
FREETMPS;
LEAVE;
Fix a number of places that produced XX000 errors in the regression tests. It's against project policy to use elog() for user-facing errors, or to omit an errcode() selection for errors that aren't supposed to be "can't happen" cases. Fix all the violations of this policy that result in ERRCODE_INTERNAL_ERROR log entries during the standard regression tests, as errors that can reliably be triggered from SQL surely should be considered user-facing. I also looked through all the files touched by this commit and fixed other nearby problems of the same ilk. I do not claim to have fixed all violations of the policy, just the ones in these files. In a few places I also changed existing ERRCODE choices that didn't seem particularly appropriate; mainly replacing ERRCODE_SYNTAX_ERROR by something more specific. Back-patch to 9.5, but no further; changing ERRCODE assignments in stable branches doesn't seem like a good idea.
2015-08-03 05:49:19 +02:00
/* XXX need to find a way to determine a better errcode here */
PL/Perl: Add event trigger support From: Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2013-12-11 14:11:59 +01:00
ereport(ERROR,
Fix a number of places that produced XX000 errors in the regression tests. It's against project policy to use elog() for user-facing errors, or to omit an errcode() selection for errors that aren't supposed to be "can't happen" cases. Fix all the violations of this policy that result in ERRCODE_INTERNAL_ERROR log entries during the standard regression tests, as errors that can reliably be triggered from SQL surely should be considered user-facing. I also looked through all the files touched by this commit and fixed other nearby problems of the same ilk. I do not claim to have fixed all violations of the policy, just the ones in these files. In a few places I also changed existing ERRCODE choices that didn't seem particularly appropriate; mainly replacing ERRCODE_SYNTAX_ERROR by something more specific. Back-patch to 9.5, but no further; changing ERRCODE assignments in stable branches doesn't seem like a good idea.
2015-08-03 05:49:19 +02:00
(errcode(ERRCODE_EXTERNAL_ROUTINE_EXCEPTION),
errmsg("%s", strip_trailing_ws(sv2cstr(ERRSV)))));
PL/Perl: Add event trigger support From: Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2013-12-11 14:11:59 +01:00
}
retval = newSVsv(POPs);
(void) retval; /* silence compiler warning */
PUTBACK;
FREETMPS;
LEAVE;
}
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
static Datum
First round of changes for new fmgr interface. fmgr itself and the key call sites are changed, but most called functions are still oldstyle. An exception is that the PL managers are updated (so, for example, NULL handling now behaves as expected in plperl and plpgsql functions). NOTE initdb is forced due to added column in pg_proc.
2000-05-28 19:56:29 +02:00
plperl_func_handler(PG_FUNCTION_ARGS)
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
{
Transaction control in PL procedures In each of the supplied procedural languages (PL/pgSQL, PL/Perl, PL/Python, PL/Tcl), add language-specific commit and rollback functions/commands to control transactions in procedures in that language. Add similar underlying functions to SPI. Some additional cleanup so that transaction commit or abort doesn't blow away data structures still used by the procedure call. Add execution context tracking to CALL and DO statements so that transaction control commands can only be issued in top-level procedure and block calls, not function calls or other procedure or block calls. - SPI Add a new function SPI_connect_ext() that is like SPI_connect() but allows passing option flags. The only option flag right now is SPI_OPT_NONATOMIC. A nonatomic SPI connection can execute transaction control commands, otherwise it's not allowed. This is meant to be passed down from CALL and DO statements which themselves know in which context they are called. A nonatomic SPI connection uses different memory management. A normal SPI connection allocates its memory in TopTransactionContext. For nonatomic connections we use PortalContext instead. As the comment in SPI_connect_ext() (previously SPI_connect()) indicates, one could potentially use PortalContext in all cases, but it seems safest to leave the existing uses alone, because this stuff is complicated enough already. SPI also gets new functions SPI_start_transaction(), SPI_commit(), and SPI_rollback(), which can be used by PLs to implement their transaction control logic. - portalmem.c Some adjustments were made in the code that cleans up portals at transaction abort. The portal code could already handle a command *committing* a transaction and continuing (e.g., VACUUM), but it was not quite prepared for a command *aborting* a transaction and continuing. In AtAbort_Portals(), remove the code that marks an active portal as failed. As the comment there already predicted, this doesn't work if the running command wants to keep running after transaction abort. And it's actually not necessary, because pquery.c is careful to run all portal code in a PG_TRY block and explicitly runs MarkPortalFailed() if there is an exception. So the code in AtAbort_Portals() is never used anyway. In AtAbort_Portals() and AtCleanup_Portals(), we need to be careful not to clean up active portals too much. This mirrors similar code in PreCommit_Portals(). - PL/Perl Gets new functions spi_commit() and spi_rollback() - PL/pgSQL Gets new commands COMMIT and ROLLBACK. Update the PL/SQL porting example in the documentation to reflect that transactions are now possible in procedures. - PL/Python Gets new functions plpy.commit and plpy.rollback. - PL/Tcl Gets new commands commit and rollback. Reviewed-by: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
2018-01-22 14:30:16 +01:00
bool nonatomic;
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
plperl_proc_desc *prodesc;
SV *perlret;
Initialize variable to quiet compiler.
2011-02-19 14:14:32 +01:00
Datum retval = 0;
At 2005-05-21 20:18:50 +0530, ams@oryx.com wrote: > > > The second issue is where plperl returns a large result set. I have attached the following seven patches to address this problem: 1. Trivial. Replaces some errant spaces with tabs. 2. Trivial. Fixes the spelling of Jan's name, and gets rid of many inane, useless, annoying, and often misleading comments. Here's a sample: "plperl_init_all() - Initialize all". (I have tried to add some useful comments here and there, and will continue to do so now and again.) 3. Trivial. Splits up some long lines. 4. Converts SRFs in PL/Perl to use a Tuplestore and SFRM_Materialize to return the result set, based on the PL/PgSQL model. There are two major consequences: result sets will spill to disk when they can no longer fit in work_mem; and "select foo_srf()" no longer works. (I didn't lose sleep over the latter, since that form is not valid in PL/PgSQL, and it's not documented in PL/Perl.) 5. Trivial, but important. Fixes use of "undef" instead of undef. This would cause empty functions to fail in bizarre ways. I suspect that there's still another (old) bug here. I'll investigate further. 6. Moves the majority of (4) out into a new plperl_return_next() function, to make it possible to expose the functionality to Perl; cleans up some of the code besides. 7. Add an spi_return_next function for use in Perl code. If you want to apply the patches and try them out, 8-composite.diff is what you should use. (Note: my patches depend upon Andrew's use-strict and %_SHARED patches being applied.) Here's something to try: create or replace function foo() returns setof record as $$ $i = 0; for ("World", "PostgreSQL", "PL/Perl") { spi_return_next({f1=>++$i, f2=>'Hello', f3=>$_}); } return; $$ language plperl; select * from foo() as (f1 integer, f2 text, f3 text); (Many thanks to Andrews Dunstan and Supernews for their help.) Abhijit Menon-Sen
2005-06-04 22:33:06 +02:00
ReturnSetInfo *rsi;
errcontext support in PL/Perl Author: Alexey Klyukin <alexk@commandprompt.com>
2009-09-16 08:06:12 +02:00
ErrorContextCallback pl_error_context;
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
Transaction control in PL procedures In each of the supplied procedural languages (PL/pgSQL, PL/Perl, PL/Python, PL/Tcl), add language-specific commit and rollback functions/commands to control transactions in procedures in that language. Add similar underlying functions to SPI. Some additional cleanup so that transaction commit or abort doesn't blow away data structures still used by the procedure call. Add execution context tracking to CALL and DO statements so that transaction control commands can only be issued in top-level procedure and block calls, not function calls or other procedure or block calls. - SPI Add a new function SPI_connect_ext() that is like SPI_connect() but allows passing option flags. The only option flag right now is SPI_OPT_NONATOMIC. A nonatomic SPI connection can execute transaction control commands, otherwise it's not allowed. This is meant to be passed down from CALL and DO statements which themselves know in which context they are called. A nonatomic SPI connection uses different memory management. A normal SPI connection allocates its memory in TopTransactionContext. For nonatomic connections we use PortalContext instead. As the comment in SPI_connect_ext() (previously SPI_connect()) indicates, one could potentially use PortalContext in all cases, but it seems safest to leave the existing uses alone, because this stuff is complicated enough already. SPI also gets new functions SPI_start_transaction(), SPI_commit(), and SPI_rollback(), which can be used by PLs to implement their transaction control logic. - portalmem.c Some adjustments were made in the code that cleans up portals at transaction abort. The portal code could already handle a command *committing* a transaction and continuing (e.g., VACUUM), but it was not quite prepared for a command *aborting* a transaction and continuing. In AtAbort_Portals(), remove the code that marks an active portal as failed. As the comment there already predicted, this doesn't work if the running command wants to keep running after transaction abort. And it's actually not necessary, because pquery.c is careful to run all portal code in a PG_TRY block and explicitly runs MarkPortalFailed() if there is an exception. So the code in AtAbort_Portals() is never used anyway. In AtAbort_Portals() and AtCleanup_Portals(), we need to be careful not to clean up active portals too much. This mirrors similar code in PreCommit_Portals(). - PL/Perl Gets new functions spi_commit() and spi_rollback() - PL/pgSQL Gets new commands COMMIT and ROLLBACK. Update the PL/SQL porting example in the documentation to reflect that transactions are now possible in procedures. - PL/Python Gets new functions plpy.commit and plpy.rollback. - PL/Tcl Gets new commands commit and rollback. Reviewed-by: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
2018-01-22 14:30:16 +01:00
nonatomic = fcinfo->context &&
IsA(fcinfo->context, CallContext) &&
!castNode(CallContext, fcinfo->context)->atomic;
if (SPI_connect_ext(nonatomic ? SPI_OPT_NONATOMIC : 0) != SPI_OK_CONNECT)
Try to instill some sanity in plperl's function result processing. Get rid of static variables for SETOF result, don't crash when called from non-FROM context, eliminate dead code, etc.
2004-11-22 21:31:53 +01:00
elog(ERROR, "could not connect to SPI manager");
PL/Perl: Add event trigger support From: Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2013-12-11 14:11:59 +01:00
prodesc = compile_plperl_function(fcinfo->flinfo->fn_oid, false, false);
Per a bug report from Theo Schlossnagle, plperl_return_next() leaks memory in the executor's per-query memory context. It also inefficient: it invokes get_call_result_type() and TupleDescGetAttInMetadata() for every call to return_next, rather than invoking them once (per PL/Perl function call) and memoizing the result. This patch makes the following changes: - refactor the code to include all the "per PL/Perl function call" data inside a single struct, "current_call_data". This means we don't need to save and restore N pointers for every recursive call into PL/Perl, we can just save and restore one. - lookup the return type metadata needed by plperl_return_next() once, and then stash it in "current_call_data", so as to avoid doing the lookup for every call to return_next. - create a temporary memory context in which to evaluate the return type's input functions. This memory context is reset for each call to return_next. The patch appears to fix the memory leak, and substantially reduces the overhead imposed by return_next.
2006-01-28 04:28:15 +01:00
current_call_data->prodesc = prodesc;
Make plperl safe against functions that are redefined while running. validate_plperl_function() supposed that it could free an old plperl_proc_desc struct immediately upon detecting that it was stale. However, if a plperl function is called recursively, this could result in deleting the struct out from under an outer invocation, leading to misbehavior or crashes. Add a simple reference-count mechanism to ensure that such structs are freed only when the last reference goes away. Per investigation of bug #7516 from Marko Tiikkaja. I am not certain that this error explains his report, because he says he didn't have any recursive calls --- but it's hard to see how else it could have crashed right there. In any case, this definitely fixes some problems in the area. Back-patch to all active branches.
2012-09-10 02:32:54 +02:00
increment_prodesc_refcount(prodesc);
Redesign query-snapshot timing so that volatile functions in READ COMMITTED mode see a fresh snapshot for each command in the function, rather than using the latest interactive command's snapshot. Also, suppress fresh snapshots as well as CommandCounterIncrement inside STABLE and IMMUTABLE functions, instead using the snapshot taken for the most closely nested regular query. (This behavior is only sane for read-only functions, so the patch also enforces that such functions contain only SELECT commands.) As per my proposal of 6-Sep-2004; I note that I floated essentially the same proposal on 19-Jun-2002, but that discussion tailed off without any action. Since 8.0 seems like the right place to be taking possibly nontrivial backwards compatibility hits, let's get it done now.
2004-09-13 22:10:13 +02:00
errcontext support in PL/Perl Author: Alexey Klyukin <alexk@commandprompt.com>
2009-09-16 08:06:12 +02:00
/* Set a callback for error reporting */
pl_error_context.callback = plperl_exec_callback;
pl_error_context.previous = error_context_stack;
pl_error_context.arg = prodesc->proname;
error_context_stack = &pl_error_context;
More rsi assignment line too.
2005-08-12 23:09:34 +02:00
rsi = (ReturnSetInfo *) fcinfo->resultinfo;
Un-break plperl for non-set case.
2005-08-12 23:26:32 +02:00
if (prodesc->fn_retisset)
> The attached patch moves a plperl sanity check into the correct > position. Performing the check in the existing position allows the call > to go through to perl first, possibly resulting in a SEGV. Andrew Dunstan
2005-08-12 22:48:03 +02:00
{
Un-break plperl for non-set case.
2005-08-12 23:26:32 +02:00
/* Check context before allowing the call to go through */
Simplify more checks related to set-returning functions This makes more consistent the SRF-related checks in the area of PL/pgSQL, PL/Perl, PL/Tcl, pageinspect and some of the JSON worker functions, making it easier to grep for the same error patterns through the code, reducing a bit the translation work. It is worth noting that each_worker_jsonb()/each_worker() in jsonfuncs.c and pageinspect's brin_page_items() were doing a check on expectedDesc that is not required as they fetch their tuple descriptor directly from get_call_result_type(). This looks like a set of copy-paste errors that have spread over the years. This commit is a continuation of the changes begun in 07daca5, for any remaining code paths on sight. Like fcc2817, this makes the code more consistent, easing the integration of a larger patch that will refactor the way tuplestores are created and checked in a good portion of the set-returning functions present in core. I have worked my way through the changes of this patch by myself, and Ranier has proposed the same changes in a different thread in parallel, though there were some inconsistencies related in expectedDesc in what was proposed by him. Author: Michael Paquier, Ranier Vilela Discussion: https://postgr.es/m/CAAKRu_azyd1Z3W_r7Ou4sorTjRCs+PxeHw1CWJeXKofkE6TuZg@mail.gmail.com Discussion: https://postgr.es/m/CAEudQApm=AFuJjEHLBjBcJbxcw4pBMwg2sHwXyCXYcbBOj3hpg@mail.gmail.com
2022-02-24 08:54:59 +01:00
if (!rsi || !IsA(rsi, ReturnSetInfo))
Un-break plperl for non-set case.
2005-08-12 23:26:32 +02:00
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
Simplify more checks related to set-returning functions This makes more consistent the SRF-related checks in the area of PL/pgSQL, PL/Perl, PL/Tcl, pageinspect and some of the JSON worker functions, making it easier to grep for the same error patterns through the code, reducing a bit the translation work. It is worth noting that each_worker_jsonb()/each_worker() in jsonfuncs.c and pageinspect's brin_page_items() were doing a check on expectedDesc that is not required as they fetch their tuple descriptor directly from get_call_result_type(). This looks like a set of copy-paste errors that have spread over the years. This commit is a continuation of the changes begun in 07daca5, for any remaining code paths on sight. Like fcc2817, this makes the code more consistent, easing the integration of a larger patch that will refactor the way tuplestores are created and checked in a good portion of the set-returning functions present in core. I have worked my way through the changes of this patch by myself, and Ranier has proposed the same changes in a different thread in parallel, though there were some inconsistencies related in expectedDesc in what was proposed by him. Author: Michael Paquier, Ranier Vilela Discussion: https://postgr.es/m/CAAKRu_azyd1Z3W_r7Ou4sorTjRCs+PxeHw1CWJeXKofkE6TuZg@mail.gmail.com Discussion: https://postgr.es/m/CAEudQApm=AFuJjEHLBjBcJbxcw4pBMwg2sHwXyCXYcbBOj3hpg@mail.gmail.com
2022-02-24 08:54:59 +01:00
errmsg("set-valued function called in context that cannot accept a set")));
if (!(rsi->allowedModes & SFRM_Materialize))
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("materialize mode required, but it is not allowed in this context")));
> The attached patch moves a plperl sanity check into the correct > position. Performing the check in the existing position allows the call > to go through to perl first, possibly resulting in a SEGV. Andrew Dunstan
2005-08-12 22:48:03 +02:00
}
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
activate_interpreter(prodesc->interp);
Force plperl and plperlu to run in separate interpreters. Create an error on an attempt to create the second interpreter if this is not supported by the perl installation. Per recent -hackers discussion.
2006-11-13 18:13:57 +01:00
At 2005-05-21 20:18:50 +0530, ams@oryx.com wrote: > > > The second issue is where plperl returns a large result set. I have attached the following seven patches to address this problem: 1. Trivial. Replaces some errant spaces with tabs. 2. Trivial. Fixes the spelling of Jan's name, and gets rid of many inane, useless, annoying, and often misleading comments. Here's a sample: "plperl_init_all() - Initialize all". (I have tried to add some useful comments here and there, and will continue to do so now and again.) 3. Trivial. Splits up some long lines. 4. Converts SRFs in PL/Perl to use a Tuplestore and SFRM_Materialize to return the result set, based on the PL/PgSQL model. There are two major consequences: result sets will spill to disk when they can no longer fit in work_mem; and "select foo_srf()" no longer works. (I didn't lose sleep over the latter, since that form is not valid in PL/PgSQL, and it's not documented in PL/Perl.) 5. Trivial, but important. Fixes use of "undef" instead of undef. This would cause empty functions to fail in bizarre ways. I suspect that there's still another (old) bug here. I'll investigate further. 6. Moves the majority of (4) out into a new plperl_return_next() function, to make it possible to expose the functionality to Perl; cleans up some of the code besides. 7. Add an spi_return_next function for use in Perl code. If you want to apply the patches and try them out, 8-composite.diff is what you should use. (Note: my patches depend upon Andrew's use-strict and %_SHARED patches being applied.) Here's something to try: create or replace function foo() returns setof record as $$ $i = 0; for ("World", "PostgreSQL", "PL/Perl") { spi_return_next({f1=>++$i, f2=>'Hello', f3=>$_}); } return; $$ language plperl; select * from foo() as (f1 integer, f2 text, f3 text); (Many thanks to Andrews Dunstan and Supernews for their help.) Abhijit Menon-Sen
2005-06-04 22:33:06 +02:00
perlret = plperl_call_perl_func(prodesc, fcinfo);
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
/************************************************************
* Disconnect from SPI manager and then create the return
* values datum (if the input function does a palloc for it
* this must not be allocated in the SPI memory context
* because SPI_finish would free it).
************************************************************/
if (SPI_finish() != SPI_OK_FINISH)
Error message editing in src/pl. The plpython module could use another look ... I'm not real certain which errors are strictly internal and which are likely to be provoked by users.
2003-07-26 01:37:31 +02:00
elog(ERROR, "SPI_finish() failed");
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
Un-break plperl for non-set case.
2005-08-12 23:26:32 +02:00
if (prodesc->fn_retisset)
Following up a previous thought I had, yesterday I realised how to return arays nicely without having to make the plperl programmer aware of anything. The attached patch allows plperl to return an arrayref where the function returns an array type. It silently calls a perl function to stringify the array before passing it to the pg array parser. Non-array returns are handled as before (i.e. passed through this process) so it is backwards compatible. I will presently submit regression tests and docs. example: andrew=# create or replace function blah() returns text[][] language plperl as $$ return [['a"b','c,d'],['e\\f','g']]; $$; CREATE FUNCTION andrew=# select blah(); blah ----------------------------- {{"a\"b","c,d"},{"e\\f",g}} This would complete half of the TODO item: . Pass arrays natively instead of as text between plperl and postgres (The other half is translating pg array arguments to perl arrays - that will have to wait for 8.1). Some of this patch is adapted from a previously submitted patch from Sergej Sergeev. Both he and Abhijit Menon-Sen have looked it over briefly and tentatively said it looks ok. Andrew Dunstan
2005-07-10 17:32:47 +02:00
{
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
SV *sav;
Un-break plperl for non-set case.
2005-08-12 23:26:32 +02:00
/*
* If the Perl function returned an arrayref, we pretend that it
At 2005-05-21 20:18:50 +0530, ams@oryx.com wrote: > > > The second issue is where plperl returns a large result set. I have attached the following seven patches to address this problem: 1. Trivial. Replaces some errant spaces with tabs. 2. Trivial. Fixes the spelling of Jan's name, and gets rid of many inane, useless, annoying, and often misleading comments. Here's a sample: "plperl_init_all() - Initialize all". (I have tried to add some useful comments here and there, and will continue to do so now and again.) 3. Trivial. Splits up some long lines. 4. Converts SRFs in PL/Perl to use a Tuplestore and SFRM_Materialize to return the result set, based on the PL/PgSQL model. There are two major consequences: result sets will spill to disk when they can no longer fit in work_mem; and "select foo_srf()" no longer works. (I didn't lose sleep over the latter, since that form is not valid in PL/PgSQL, and it's not documented in PL/Perl.) 5. Trivial, but important. Fixes use of "undef" instead of undef. This would cause empty functions to fail in bizarre ways. I suspect that there's still another (old) bug here. I'll investigate further. 6. Moves the majority of (4) out into a new plperl_return_next() function, to make it possible to expose the functionality to Perl; cleans up some of the code besides. 7. Add an spi_return_next function for use in Perl code. If you want to apply the patches and try them out, 8-composite.diff is what you should use. (Note: my patches depend upon Andrew's use-strict and %_SHARED patches being applied.) Here's something to try: create or replace function foo() returns setof record as $$ $i = 0; for ("World", "PostgreSQL", "PL/Perl") { spi_return_next({f1=>++$i, f2=>'Hello', f3=>$_}); } return; $$ language plperl; select * from foo() as (f1 integer, f2 text, f3 text); (Many thanks to Andrews Dunstan and Supernews for their help.) Abhijit Menon-Sen
2005-06-04 22:33:06 +02:00
* called return_next() for each element of the array, to handle old
* SRFs that didn't know about return_next(). Any other sort of return
Fix incorrect tests for undef Perl values in some places in plperl.c. The correct test for defined-ness is SvOK(sv), not anything involving SvTYPE. Per bug #3415 from Matt Taylor. Back-patch as far as 8.0; no apparent problem in 7.x.
2007-06-28 19:49:59 +02:00
* value is an error, except undef which means return an empty set.
Un-break plperl for non-set case.
2005-08-12 23:26:32 +02:00
*/
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
sav = get_perl_array_ref(perlret);
if (sav)
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
{
PL/Perl portability fix: avoid including XSUB.h in plperl.c. In Perl builds that define PERL_IMPLICIT_SYS, XSUB.h defines macros that replace a whole lot of basic libc functions with Perl functions. We can't tolerate that in plperl.c; it breaks at least PG_TRY and probably other stuff. The core idea of this patch is to include XSUB.h only in the .xs files where it's really needed, and to move any code broken by PERL_IMPLICIT_SYS out of the .xs files and into plperl.c. The reason this hasn't been a problem before is that our build techniques did not result in PERL_IMPLICIT_SYS appearing as a #define in PL/Perl, even on some platforms where Perl thinks it is defined. That's about to change in order to fix a nasty portability issue, so we need this work to make the code safe for that. Rather unaccountably, the Perl people chose XSUB.h as the place to provide the versions of the aTHX/aTHX_ macros that are needed by code that's not explicitly aware of the MULTIPLICITY API conventions. Hence, just removing XSUB.h from plperl.c fails miserably. But we can work around that by defining PERL_NO_GET_CONTEXT (which would make the relevant stanza of XSUB.h a no-op anyway). As explained in perlguts.pod, that means we need to add a "dTHX" macro call in every C function that calls a Perl API function. In most of them we just add this at the top; but since the macro fetches the current Perl interpreter pointer, more care is needed in functions that switch the active interpreter. Lack of the macro is easily recognized since it results in bleats about "my_perl" not being defined. (A nice side benefit of this is that it significantly reduces the number of fetches of the current interpreter pointer. On my machine, plperl.so gets more than 10% smaller, and there's probably some performance win too. We could reduce the number of fetches still more by decorating the code with pTHX_/aTHX_ macros to pass the interpreter pointer around, as explained by perlguts.pod; but that's a task for another day.) Formatting note: pgindent seems happy to treat "dTHX;" as a declaration so long as it's the first thing after the left brace, as we'd already observed with respect to the similar macro "dSP;". If you try to put it later in a set of declarations, pgindent puts ugly extra space around it. Having removed XSUB.h from plperl.c, we need only move the support functions for spi_return_next and util_elog (both of which use PG_TRY) out of the .xs files and into plperl.c. This seems sufficient to avoid the known problems caused by PERL_IMPLICIT_SYS, although we could move more code if additional issues emerge. This will need to be back-patched, but first let's see what the buildfarm makes of it. Patch by me, with some help from Ashutosh Sharma Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
2017-07-28 18:25:43 +02:00
dTHX;
At 2005-05-21 20:18:50 +0530, ams@oryx.com wrote: > > > The second issue is where plperl returns a large result set. I have attached the following seven patches to address this problem: 1. Trivial. Replaces some errant spaces with tabs. 2. Trivial. Fixes the spelling of Jan's name, and gets rid of many inane, useless, annoying, and often misleading comments. Here's a sample: "plperl_init_all() - Initialize all". (I have tried to add some useful comments here and there, and will continue to do so now and again.) 3. Trivial. Splits up some long lines. 4. Converts SRFs in PL/Perl to use a Tuplestore and SFRM_Materialize to return the result set, based on the PL/PgSQL model. There are two major consequences: result sets will spill to disk when they can no longer fit in work_mem; and "select foo_srf()" no longer works. (I didn't lose sleep over the latter, since that form is not valid in PL/PgSQL, and it's not documented in PL/Perl.) 5. Trivial, but important. Fixes use of "undef" instead of undef. This would cause empty functions to fail in bizarre ways. I suspect that there's still another (old) bug here. I'll investigate further. 6. Moves the majority of (4) out into a new plperl_return_next() function, to make it possible to expose the functionality to Perl; cleans up some of the code besides. 7. Add an spi_return_next function for use in Perl code. If you want to apply the patches and try them out, 8-composite.diff is what you should use. (Note: my patches depend upon Andrew's use-strict and %_SHARED patches being applied.) Here's something to try: create or replace function foo() returns setof record as $$ $i = 0; for ("World", "PostgreSQL", "PL/Perl") { spi_return_next({f1=>++$i, f2=>'Hello', f3=>$_}); } return; $$ language plperl; select * from foo() as (f1 integer, f2 text, f3 text); (Many thanks to Andrews Dunstan and Supernews for their help.) Abhijit Menon-Sen
2005-06-04 22:33:06 +02:00
int i = 0;
SV **svp = 0;
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
AV *rav = (AV *) SvRV(sav);
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
Following up a previous thought I had, yesterday I realised how to return arays nicely without having to make the plperl programmer aware of anything. The attached patch allows plperl to return an arrayref where the function returns an array type. It silently calls a perl function to stringify the array before passing it to the pg array parser. Non-array returns are handled as before (i.e. passed through this process) so it is backwards compatible. I will presently submit regression tests and docs. example: andrew=# create or replace function blah() returns text[][] language plperl as $$ return [['a"b','c,d'],['e\\f','g']]; $$; CREATE FUNCTION andrew=# select blah(); blah ----------------------------- {{"a\"b","c,d"},{"e\\f",g}} This would complete half of the TODO item: . Pass arrays natively instead of as text between plperl and postgres (The other half is translating pg array arguments to perl arrays - that will have to wait for 8.1). Some of this patch is adapted from a previously submitted patch from Sergej Sergeev. Both he and Abhijit Menon-Sen have looked it over briefly and tentatively said it looks ok. Andrew Dunstan
2005-07-10 17:32:47 +02:00
while ((svp = av_fetch(rav, i, FALSE)) != NULL)
{
PL/Perl portability fix: avoid including XSUB.h in plperl.c. In Perl builds that define PERL_IMPLICIT_SYS, XSUB.h defines macros that replace a whole lot of basic libc functions with Perl functions. We can't tolerate that in plperl.c; it breaks at least PG_TRY and probably other stuff. The core idea of this patch is to include XSUB.h only in the .xs files where it's really needed, and to move any code broken by PERL_IMPLICIT_SYS out of the .xs files and into plperl.c. The reason this hasn't been a problem before is that our build techniques did not result in PERL_IMPLICIT_SYS appearing as a #define in PL/Perl, even on some platforms where Perl thinks it is defined. That's about to change in order to fix a nasty portability issue, so we need this work to make the code safe for that. Rather unaccountably, the Perl people chose XSUB.h as the place to provide the versions of the aTHX/aTHX_ macros that are needed by code that's not explicitly aware of the MULTIPLICITY API conventions. Hence, just removing XSUB.h from plperl.c fails miserably. But we can work around that by defining PERL_NO_GET_CONTEXT (which would make the relevant stanza of XSUB.h a no-op anyway). As explained in perlguts.pod, that means we need to add a "dTHX" macro call in every C function that calls a Perl API function. In most of them we just add this at the top; but since the macro fetches the current Perl interpreter pointer, more care is needed in functions that switch the active interpreter. Lack of the macro is easily recognized since it results in bleats about "my_perl" not being defined. (A nice side benefit of this is that it significantly reduces the number of fetches of the current interpreter pointer. On my machine, plperl.so gets more than 10% smaller, and there's probably some performance win too. We could reduce the number of fetches still more by decorating the code with pTHX_/aTHX_ macros to pass the interpreter pointer around, as explained by perlguts.pod; but that's a task for another day.) Formatting note: pgindent seems happy to treat "dTHX;" as a declaration so long as it's the first thing after the left brace, as we'd already observed with respect to the similar macro "dSP;". If you try to put it later in a set of declarations, pgindent puts ugly extra space around it. Having removed XSUB.h from plperl.c, we need only move the support functions for spi_return_next and util_elog (both of which use PG_TRY) out of the .xs files and into plperl.c. This seems sufficient to avoid the known problems caused by PERL_IMPLICIT_SYS, although we could move more code if additional issues emerge. This will need to be back-patched, but first let's see what the buildfarm makes of it. Patch by me, with some help from Ashutosh Sharma Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
2017-07-28 18:25:43 +02:00
plperl_return_next_internal(*svp);
At 2005-05-21 20:18:50 +0530, ams@oryx.com wrote: > > > The second issue is where plperl returns a large result set. I have attached the following seven patches to address this problem: 1. Trivial. Replaces some errant spaces with tabs. 2. Trivial. Fixes the spelling of Jan's name, and gets rid of many inane, useless, annoying, and often misleading comments. Here's a sample: "plperl_init_all() - Initialize all". (I have tried to add some useful comments here and there, and will continue to do so now and again.) 3. Trivial. Splits up some long lines. 4. Converts SRFs in PL/Perl to use a Tuplestore and SFRM_Materialize to return the result set, based on the PL/PgSQL model. There are two major consequences: result sets will spill to disk when they can no longer fit in work_mem; and "select foo_srf()" no longer works. (I didn't lose sleep over the latter, since that form is not valid in PL/PgSQL, and it's not documented in PL/Perl.) 5. Trivial, but important. Fixes use of "undef" instead of undef. This would cause empty functions to fail in bizarre ways. I suspect that there's still another (old) bug here. I'll investigate further. 6. Moves the majority of (4) out into a new plperl_return_next() function, to make it possible to expose the functionality to Perl; cleans up some of the code besides. 7. Add an spi_return_next function for use in Perl code. If you want to apply the patches and try them out, 8-composite.diff is what you should use. (Note: my patches depend upon Andrew's use-strict and %_SHARED patches being applied.) Here's something to try: create or replace function foo() returns setof record as $$ $i = 0; for ("World", "PostgreSQL", "PL/Perl") { spi_return_next({f1=>++$i, f2=>'Hello', f3=>$_}); } return; $$ language plperl; select * from foo() as (f1 integer, f2 text, f3 text); (Many thanks to Andrews Dunstan and Supernews for their help.) Abhijit Menon-Sen
2005-06-04 22:33:06 +02:00
i++;
}
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
}
Fix incorrect tests for undef Perl values in some places in plperl.c. The correct test for defined-ness is SvOK(sv), not anything involving SvTYPE. Per bug #3415 from Matt Taylor. Back-patch as far as 8.0; no apparent problem in 7.x.
2007-06-28 19:49:59 +02:00
else if (SvOK(perlret))
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
{
Update plperl to use ereport() not elog() for user-facing messages, so that they will be translatable. Give messages some semblance of conformance to the style guide.
2004-11-29 21:11:06 +01:00
ereport(ERROR,
(errcode(ERRCODE_DATATYPE_MISMATCH),
Wordsmithing for PL/Perl messages
2009-02-19 11:33:17 +01:00
errmsg("set-returning PL/Perl function must return "
At 2005-05-21 20:18:50 +0530, ams@oryx.com wrote: > > > The second issue is where plperl returns a large result set. I have attached the following seven patches to address this problem: 1. Trivial. Replaces some errant spaces with tabs. 2. Trivial. Fixes the spelling of Jan's name, and gets rid of many inane, useless, annoying, and often misleading comments. Here's a sample: "plperl_init_all() - Initialize all". (I have tried to add some useful comments here and there, and will continue to do so now and again.) 3. Trivial. Splits up some long lines. 4. Converts SRFs in PL/Perl to use a Tuplestore and SFRM_Materialize to return the result set, based on the PL/PgSQL model. There are two major consequences: result sets will spill to disk when they can no longer fit in work_mem; and "select foo_srf()" no longer works. (I didn't lose sleep over the latter, since that form is not valid in PL/PgSQL, and it's not documented in PL/Perl.) 5. Trivial, but important. Fixes use of "undef" instead of undef. This would cause empty functions to fail in bizarre ways. I suspect that there's still another (old) bug here. I'll investigate further. 6. Moves the majority of (4) out into a new plperl_return_next() function, to make it possible to expose the functionality to Perl; cleans up some of the code besides. 7. Add an spi_return_next function for use in Perl code. If you want to apply the patches and try them out, 8-composite.diff is what you should use. (Note: my patches depend upon Andrew's use-strict and %_SHARED patches being applied.) Here's something to try: create or replace function foo() returns setof record as $$ $i = 0; for ("World", "PostgreSQL", "PL/Perl") { spi_return_next({f1=>++$i, f2=>'Hello', f3=>$_}); } return; $$ language plperl; select * from foo() as (f1 integer, f2 text, f3 text); (Many thanks to Andrews Dunstan and Supernews for their help.) Abhijit Menon-Sen
2005-06-04 22:33:06 +02:00
"reference to array or use return_next")));
The attached patch, which incorporates the previous one sent and currently unapplied regarding spi_internal.c, makes some additional fixes relating to return types, and also contains the fix for preventing the use of insecure versions of Safe.pm. There is one remaing return case that does not appear to work, namely return of a composite directly in a select, i.e. if foo returns some composite type, 'select * from foo()' works but 'select foo()' doesn't. We will either fix that or document it as a limitation. The function plperl_func_handler is a mess - I will try to get it cleaned up (and split up) in a subsequent patch, time permitting. Also, reiterating previous advice - this changes slightly the API for spi_exec_query - the returned object has either 2 or 3 members: 'status' (string) and 'proceesed' (int,- number of rows) and, if rows are returned, 'rows' (array of tuple hashes). Andrew Dunstan
2004-07-12 16:31:04 +02:00
}
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
At 2005-05-21 20:18:50 +0530, ams@oryx.com wrote: > > > The second issue is where plperl returns a large result set. I have attached the following seven patches to address this problem: 1. Trivial. Replaces some errant spaces with tabs. 2. Trivial. Fixes the spelling of Jan's name, and gets rid of many inane, useless, annoying, and often misleading comments. Here's a sample: "plperl_init_all() - Initialize all". (I have tried to add some useful comments here and there, and will continue to do so now and again.) 3. Trivial. Splits up some long lines. 4. Converts SRFs in PL/Perl to use a Tuplestore and SFRM_Materialize to return the result set, based on the PL/PgSQL model. There are two major consequences: result sets will spill to disk when they can no longer fit in work_mem; and "select foo_srf()" no longer works. (I didn't lose sleep over the latter, since that form is not valid in PL/PgSQL, and it's not documented in PL/Perl.) 5. Trivial, but important. Fixes use of "undef" instead of undef. This would cause empty functions to fail in bizarre ways. I suspect that there's still another (old) bug here. I'll investigate further. 6. Moves the majority of (4) out into a new plperl_return_next() function, to make it possible to expose the functionality to Perl; cleans up some of the code besides. 7. Add an spi_return_next function for use in Perl code. If you want to apply the patches and try them out, 8-composite.diff is what you should use. (Note: my patches depend upon Andrew's use-strict and %_SHARED patches being applied.) Here's something to try: create or replace function foo() returns setof record as $$ $i = 0; for ("World", "PostgreSQL", "PL/Perl") { spi_return_next({f1=>++$i, f2=>'Hello', f3=>$_}); } return; $$ language plperl; select * from foo() as (f1 integer, f2 text, f3 text); (Many thanks to Andrews Dunstan and Supernews for their help.) Abhijit Menon-Sen
2005-06-04 22:33:06 +02:00
rsi->returnMode = SFRM_Materialize;
Per a bug report from Theo Schlossnagle, plperl_return_next() leaks memory in the executor's per-query memory context. It also inefficient: it invokes get_call_result_type() and TupleDescGetAttInMetadata() for every call to return_next, rather than invoking them once (per PL/Perl function call) and memoizing the result. This patch makes the following changes: - refactor the code to include all the "per PL/Perl function call" data inside a single struct, "current_call_data". This means we don't need to save and restore N pointers for every recursive call into PL/Perl, we can just save and restore one. - lookup the return type metadata needed by plperl_return_next() once, and then stash it in "current_call_data", so as to avoid doing the lookup for every call to return_next. - create a temporary memory context in which to evaluate the return type's input functions. This memory context is reset for each call to return_next. The patch appears to fix the memory leak, and substantially reduces the overhead imposed by return_next.
2006-01-28 04:28:15 +01:00
if (current_call_data->tuple_store)
Following up a previous thought I had, yesterday I realised how to return arays nicely without having to make the plperl programmer aware of anything. The attached patch allows plperl to return an arrayref where the function returns an array type. It silently calls a perl function to stringify the array before passing it to the pg array parser. Non-array returns are handled as before (i.e. passed through this process) so it is backwards compatible. I will presently submit regression tests and docs. example: andrew=# create or replace function blah() returns text[][] language plperl as $$ return [['a"b','c,d'],['e\\f','g']]; $$; CREATE FUNCTION andrew=# select blah(); blah ----------------------------- {{"a\"b","c,d"},{"e\\f",g}} This would complete half of the TODO item: . Pass arrays natively instead of as text between plperl and postgres (The other half is translating pg array arguments to perl arrays - that will have to wait for 8.1). Some of this patch is adapted from a previously submitted patch from Sergej Sergeev. Both he and Abhijit Menon-Sen have looked it over briefly and tentatively said it looks ok. Andrew Dunstan
2005-07-10 17:32:47 +02:00
{
Per a bug report from Theo Schlossnagle, plperl_return_next() leaks memory in the executor's per-query memory context. It also inefficient: it invokes get_call_result_type() and TupleDescGetAttInMetadata() for every call to return_next, rather than invoking them once (per PL/Perl function call) and memoizing the result. This patch makes the following changes: - refactor the code to include all the "per PL/Perl function call" data inside a single struct, "current_call_data". This means we don't need to save and restore N pointers for every recursive call into PL/Perl, we can just save and restore one. - lookup the return type metadata needed by plperl_return_next() once, and then stash it in "current_call_data", so as to avoid doing the lookup for every call to return_next. - create a temporary memory context in which to evaluate the return type's input functions. This memory context is reset for each call to return_next. The patch appears to fix the memory leak, and substantially reduces the overhead imposed by return_next.
2006-01-28 04:28:15 +01:00
rsi->setResult = current_call_data->tuple_store;
rsi->setDesc = current_call_data->ret_tdesc;
The attached patch, which incorporates the previous one sent and currently unapplied regarding spi_internal.c, makes some additional fixes relating to return types, and also contains the fix for preventing the use of insecure versions of Safe.pm. There is one remaing return case that does not appear to work, namely return of a composite directly in a select, i.e. if foo returns some composite type, 'select * from foo()' works but 'select foo()' doesn't. We will either fix that or document it as a limitation. The function plperl_func_handler is a mess - I will try to get it cleaned up (and split up) in a subsequent patch, time permitting. Also, reiterating previous advice - this changes slightly the API for spi_exec_query - the returned object has either 2 or 3 members: 'status' (string) and 'proceesed' (int,- number of rows) and, if rows are returned, 'rows' (array of tuple hashes). Andrew Dunstan
2004-07-12 16:31:04 +02:00
}
At 2005-05-21 20:18:50 +0530, ams@oryx.com wrote: > > > The second issue is where plperl returns a large result set. I have attached the following seven patches to address this problem: 1. Trivial. Replaces some errant spaces with tabs. 2. Trivial. Fixes the spelling of Jan's name, and gets rid of many inane, useless, annoying, and often misleading comments. Here's a sample: "plperl_init_all() - Initialize all". (I have tried to add some useful comments here and there, and will continue to do so now and again.) 3. Trivial. Splits up some long lines. 4. Converts SRFs in PL/Perl to use a Tuplestore and SFRM_Materialize to return the result set, based on the PL/PgSQL model. There are two major consequences: result sets will spill to disk when they can no longer fit in work_mem; and "select foo_srf()" no longer works. (I didn't lose sleep over the latter, since that form is not valid in PL/PgSQL, and it's not documented in PL/Perl.) 5. Trivial, but important. Fixes use of "undef" instead of undef. This would cause empty functions to fail in bizarre ways. I suspect that there's still another (old) bug here. I'll investigate further. 6. Moves the majority of (4) out into a new plperl_return_next() function, to make it possible to expose the functionality to Perl; cleans up some of the code besides. 7. Add an spi_return_next function for use in Perl code. If you want to apply the patches and try them out, 8-composite.diff is what you should use. (Note: my patches depend upon Andrew's use-strict and %_SHARED patches being applied.) Here's something to try: create or replace function foo() returns setof record as $$ $i = 0; for ("World", "PostgreSQL", "PL/Perl") { spi_return_next({f1=>++$i, f2=>'Hello', f3=>$_}); } return; $$ language plperl; select * from foo() as (f1 integer, f2 text, f3 text); (Many thanks to Andrews Dunstan and Supernews for their help.) Abhijit Menon-Sen
2005-06-04 22:33:06 +02:00
retval = (Datum) 0;
}
SQL procedures This adds a new object type "procedure" that is similar to a function but does not have a return type and is invoked by the new CALL statement instead of SELECT or similar. This implementation is aligned with the SQL standard and compatible with or similar to other SQL implementations. This commit adds new commands CALL, CREATE/ALTER/DROP PROCEDURE, as well as ALTER/DROP ROUTINE that can refer to either a function or a procedure (or an aggregate function, as an extension to SQL). There is also support for procedures in various utility commands such as COMMENT and GRANT, as well as support in pg_dump and psql. Support for defining procedures is available in all the languages supplied by the core distribution. While this commit is mainly syntax sugar around existing functionality, future features will rely on having procedures as a separate object type. Reviewed-by: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
2017-11-30 14:46:13 +01:00
else if (prodesc->result_oid)
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
{
retval = plperl_sv_to_datum(perlret,
prodesc->result_oid,
Fix up Perl-to-Postgres datatype conversions in pl/perl. This patch restores the pre-9.1 behavior that pl/perl functions returning VOID ignore the result value of their last Perl statement. 9.1.0 unintentionally threw an error if the last statement returned a reference, as reported by Amit Khandekar. Also, make sure it works to return a string value for a composite type, so long as the string meets the type's input format. We already allowed the equivalent behavior for arrays, so it seems inconsistent to not allow it for composites. In addition, ensure we throw errors for attempts to return arrays or hashes when the function's declared result type is not an array or composite type, respectively. Pre-9.1 versions rather uselessly returned strings like ARRAY(0x221a9a0) or HASH(0x221aa90), while 9.1.0 threw an error for the hash case and returned a garbage value for the array case. Also, clean up assorted grotty coding in Perl array conversion, including use of a session-lifespan memory context to accumulate the array value (resulting in session-lifespan memory leak on error), failure to apply the declared typmod if any, and failure to detect some cases of non-rectangular multi-dimensional arrays. Alex Hunsaker and Tom Lane
2011-10-14 00:02:43 +02:00
-1,
fcinfo,
&prodesc->result_in_func,
prodesc->result_typioparam,
&fcinfo->isnull);
if (fcinfo->isnull && rsi && IsA(rsi, ReturnSetInfo))
rsi->isDone = ExprEndResult;
First round of changes for new fmgr interface. fmgr itself and the key call sites are changed, but most called functions are still oldstyle. An exception is that the PL managers are updated (so, for example, NULL handling now behaves as expected in plperl and plpgsql functions). NOTE initdb is forced due to added column in pg_proc.
2000-05-28 19:56:29 +02:00
}
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
errcontext support in PL/Perl Author: Alexey Klyukin <alexk@commandprompt.com>
2009-09-16 08:06:12 +02:00
/* Restore the previous error callback */
error_context_stack = pl_error_context.previous;
Add support for anonymous code blocks (DO blocks) to PL/Perl. Joshua Tolley, reviewed by Brendan Jurd and Tim Bunce
2009-11-29 04:02:27 +01:00
PL/Perl portability fix: avoid including XSUB.h in plperl.c. In Perl builds that define PERL_IMPLICIT_SYS, XSUB.h defines macros that replace a whole lot of basic libc functions with Perl functions. We can't tolerate that in plperl.c; it breaks at least PG_TRY and probably other stuff. The core idea of this patch is to include XSUB.h only in the .xs files where it's really needed, and to move any code broken by PERL_IMPLICIT_SYS out of the .xs files and into plperl.c. The reason this hasn't been a problem before is that our build techniques did not result in PERL_IMPLICIT_SYS appearing as a #define in PL/Perl, even on some platforms where Perl thinks it is defined. That's about to change in order to fix a nasty portability issue, so we need this work to make the code safe for that. Rather unaccountably, the Perl people chose XSUB.h as the place to provide the versions of the aTHX/aTHX_ macros that are needed by code that's not explicitly aware of the MULTIPLICITY API conventions. Hence, just removing XSUB.h from plperl.c fails miserably. But we can work around that by defining PERL_NO_GET_CONTEXT (which would make the relevant stanza of XSUB.h a no-op anyway). As explained in perlguts.pod, that means we need to add a "dTHX" macro call in every C function that calls a Perl API function. In most of them we just add this at the top; but since the macro fetches the current Perl interpreter pointer, more care is needed in functions that switch the active interpreter. Lack of the macro is easily recognized since it results in bleats about "my_perl" not being defined. (A nice side benefit of this is that it significantly reduces the number of fetches of the current interpreter pointer. On my machine, plperl.so gets more than 10% smaller, and there's probably some performance win too. We could reduce the number of fetches still more by decorating the code with pTHX_/aTHX_ macros to pass the interpreter pointer around, as explained by perlguts.pod; but that's a task for another day.) Formatting note: pgindent seems happy to treat "dTHX;" as a declaration so long as it's the first thing after the left brace, as we'd already observed with respect to the similar macro "dSP;". If you try to put it later in a set of declarations, pgindent puts ugly extra space around it. Having removed XSUB.h from plperl.c, we need only move the support functions for spi_return_next and util_elog (both of which use PG_TRY) out of the .xs files and into plperl.c. This seems sufficient to avoid the known problems caused by PERL_IMPLICIT_SYS, although we could move more code if additional issues emerge. This will need to be back-patched, but first let's see what the buildfarm makes of it. Patch by me, with some help from Ashutosh Sharma Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
2017-07-28 18:25:43 +02:00
SvREFCNT_dec_current(perlret);
Fix plperl to do recursion safely, and fix a problem with array results. Add suitable regression tests. Andrew Dunstan
2005-07-12 03:16:22 +02:00
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
return retval;
}
At 2005-05-21 20:18:50 +0530, ams@oryx.com wrote: > > > The second issue is where plperl returns a large result set. I have attached the following seven patches to address this problem: 1. Trivial. Replaces some errant spaces with tabs. 2. Trivial. Fixes the spelling of Jan's name, and gets rid of many inane, useless, annoying, and often misleading comments. Here's a sample: "plperl_init_all() - Initialize all". (I have tried to add some useful comments here and there, and will continue to do so now and again.) 3. Trivial. Splits up some long lines. 4. Converts SRFs in PL/Perl to use a Tuplestore and SFRM_Materialize to return the result set, based on the PL/PgSQL model. There are two major consequences: result sets will spill to disk when they can no longer fit in work_mem; and "select foo_srf()" no longer works. (I didn't lose sleep over the latter, since that form is not valid in PL/PgSQL, and it's not documented in PL/Perl.) 5. Trivial, but important. Fixes use of "undef" instead of undef. This would cause empty functions to fail in bizarre ways. I suspect that there's still another (old) bug here. I'll investigate further. 6. Moves the majority of (4) out into a new plperl_return_next() function, to make it possible to expose the functionality to Perl; cleans up some of the code besides. 7. Add an spi_return_next function for use in Perl code. If you want to apply the patches and try them out, 8-composite.diff is what you should use. (Note: my patches depend upon Andrew's use-strict and %_SHARED patches being applied.) Here's something to try: create or replace function foo() returns setof record as $$ $i = 0; for ("World", "PostgreSQL", "PL/Perl") { spi_return_next({f1=>++$i, f2=>'Hello', f3=>$_}); } return; $$ language plperl; select * from foo() as (f1 integer, f2 text, f3 text); (Many thanks to Andrews Dunstan and Supernews for their help.) Abhijit Menon-Sen
2005-06-04 22:33:06 +02:00
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
static Datum
plperl_trigger_handler(PG_FUNCTION_ARGS)
{
plperl_proc_desc *prodesc;
SV *perlret;
Datum retval;
SV *svTD;
HV *hvTD;
errcontext support in PL/Perl Author: Alexey Klyukin <alexk@commandprompt.com>
2009-09-16 08:06:12 +02:00
ErrorContextCallback pl_error_context;
Follow-on cleanup for the transition table patch. Commit 59702716 added transition table support to PL/pgsql so that SQL queries in trigger functions could access those transient tables. In order to provide the same level of support for PL/perl, PL/python and PL/tcl, refactor the relevant code into a new function SPI_register_trigger_data. Call the new function in the trigger handler of all four PLs, and document it as a public SPI function so that authors of out-of-tree PLs can do the same. Also get rid of a second QueryEnvironment object that was maintained by PL/pgsql. That was previously used to deal with cursors, but the same approach wasn't appropriate for PLs that are less tangled up with core code. Instead, have SPI_cursor_open install the connection's current QueryEnvironment, as already happens for SPI_execute_plan. While in the docs, remove the note that transition tables were only supported in C and PL/pgSQL triggers, and correct some ommissions. Thomas Munro with some work by Kevin Grittner (mostly docs)
2017-04-05 01:36:39 +02:00
TriggerData *tdata;
int rc PG_USED_FOR_ASSERTS_ONLY;
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
Try to instill some sanity in plperl's function result processing. Get rid of static variables for SETOF result, don't crash when called from non-FROM context, eliminate dead code, etc.
2004-11-22 21:31:53 +01:00
/* Connect to SPI manager */
if (SPI_connect() != SPI_OK_CONNECT)
elog(ERROR, "could not connect to SPI manager");
Follow-on cleanup for the transition table patch. Commit 59702716 added transition table support to PL/pgsql so that SQL queries in trigger functions could access those transient tables. In order to provide the same level of support for PL/perl, PL/python and PL/tcl, refactor the relevant code into a new function SPI_register_trigger_data. Call the new function in the trigger handler of all four PLs, and document it as a public SPI function so that authors of out-of-tree PLs can do the same. Also get rid of a second QueryEnvironment object that was maintained by PL/pgsql. That was previously used to deal with cursors, but the same approach wasn't appropriate for PLs that are less tangled up with core code. Instead, have SPI_cursor_open install the connection's current QueryEnvironment, as already happens for SPI_execute_plan. While in the docs, remove the note that transition tables were only supported in C and PL/pgSQL triggers, and correct some ommissions. Thomas Munro with some work by Kevin Grittner (mostly docs)
2017-04-05 01:36:39 +02:00
/* Make transition tables visible to this SPI connection */
tdata = (TriggerData *) fcinfo->context;
rc = SPI_register_trigger_data(tdata);
Assert(rc >= 0);
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
/* Find or compile the function */
PL/Perl: Add event trigger support From: Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2013-12-11 14:11:59 +01:00
prodesc = compile_plperl_function(fcinfo->flinfo->fn_oid, true, false);
Per a bug report from Theo Schlossnagle, plperl_return_next() leaks memory in the executor's per-query memory context. It also inefficient: it invokes get_call_result_type() and TupleDescGetAttInMetadata() for every call to return_next, rather than invoking them once (per PL/Perl function call) and memoizing the result. This patch makes the following changes: - refactor the code to include all the "per PL/Perl function call" data inside a single struct, "current_call_data". This means we don't need to save and restore N pointers for every recursive call into PL/Perl, we can just save and restore one. - lookup the return type metadata needed by plperl_return_next() once, and then stash it in "current_call_data", so as to avoid doing the lookup for every call to return_next. - create a temporary memory context in which to evaluate the return type's input functions. This memory context is reset for each call to return_next. The patch appears to fix the memory leak, and substantially reduces the overhead imposed by return_next.
2006-01-28 04:28:15 +01:00
current_call_data->prodesc = prodesc;
Make plperl safe against functions that are redefined while running. validate_plperl_function() supposed that it could free an old plperl_proc_desc struct immediately upon detecting that it was stale. However, if a plperl function is called recursively, this could result in deleting the struct out from under an outer invocation, leading to misbehavior or crashes. Add a simple reference-count mechanism to ensure that such structs are freed only when the last reference goes away. Per investigation of bug #7516 from Marko Tiikkaja. I am not certain that this error explains his report, because he says he didn't have any recursive calls --- but it's hard to see how else it could have crashed right there. In any case, this definitely fixes some problems in the area. Back-patch to all active branches.
2012-09-10 02:32:54 +02:00
increment_prodesc_refcount(prodesc);
Redesign query-snapshot timing so that volatile functions in READ COMMITTED mode see a fresh snapshot for each command in the function, rather than using the latest interactive command's snapshot. Also, suppress fresh snapshots as well as CommandCounterIncrement inside STABLE and IMMUTABLE functions, instead using the snapshot taken for the most closely nested regular query. (This behavior is only sane for read-only functions, so the patch also enforces that such functions contain only SELECT commands.) As per my proposal of 6-Sep-2004; I note that I floated essentially the same proposal on 19-Jun-2002, but that discussion tailed off without any action. Since 8.0 seems like the right place to be taking possibly nontrivial backwards compatibility hits, let's get it done now.
2004-09-13 22:10:13 +02:00
errcontext support in PL/Perl Author: Alexey Klyukin <alexk@commandprompt.com>
2009-09-16 08:06:12 +02:00
/* Set a callback for error reporting */
pl_error_context.callback = plperl_exec_callback;
pl_error_context.previous = error_context_stack;
pl_error_context.arg = prodesc->proname;
error_context_stack = &pl_error_context;
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
activate_interpreter(prodesc->interp);
Force plperl and plperlu to run in separate interpreters. Create an error on an attempt to create the second interpreter if this is not supported by the perl installation. Per recent -hackers discussion.
2006-11-13 18:13:57 +01:00
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
svTD = plperl_trigger_build_args(fcinfo);
perlret = plperl_call_perl_trigger_func(prodesc, fcinfo, svTD);
At 2005-05-21 20:18:50 +0530, ams@oryx.com wrote: > > > The second issue is where plperl returns a large result set. I have attached the following seven patches to address this problem: 1. Trivial. Replaces some errant spaces with tabs. 2. Trivial. Fixes the spelling of Jan's name, and gets rid of many inane, useless, annoying, and often misleading comments. Here's a sample: "plperl_init_all() - Initialize all". (I have tried to add some useful comments here and there, and will continue to do so now and again.) 3. Trivial. Splits up some long lines. 4. Converts SRFs in PL/Perl to use a Tuplestore and SFRM_Materialize to return the result set, based on the PL/PgSQL model. There are two major consequences: result sets will spill to disk when they can no longer fit in work_mem; and "select foo_srf()" no longer works. (I didn't lose sleep over the latter, since that form is not valid in PL/PgSQL, and it's not documented in PL/Perl.) 5. Trivial, but important. Fixes use of "undef" instead of undef. This would cause empty functions to fail in bizarre ways. I suspect that there's still another (old) bug here. I'll investigate further. 6. Moves the majority of (4) out into a new plperl_return_next() function, to make it possible to expose the functionality to Perl; cleans up some of the code besides. 7. Add an spi_return_next function for use in Perl code. If you want to apply the patches and try them out, 8-composite.diff is what you should use. (Note: my patches depend upon Andrew's use-strict and %_SHARED patches being applied.) Here's something to try: create or replace function foo() returns setof record as $$ $i = 0; for ("World", "PostgreSQL", "PL/Perl") { spi_return_next({f1=>++$i, f2=>'Hello', f3=>$_}); } return; $$ language plperl; select * from foo() as (f1 integer, f2 text, f3 text); (Many thanks to Andrews Dunstan and Supernews for their help.) Abhijit Menon-Sen
2005-06-04 22:33:06 +02:00
hvTD = (HV *) SvRV(svTD);
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
/************************************************************
* Disconnect from SPI manager and then create the return
* values datum (if the input function does a palloc for it
* this must not be allocated in the SPI memory context
* because SPI_finish would free it).
************************************************************/
if (SPI_finish() != SPI_OK_FINISH)
Update plperl to use ereport() not elog() for user-facing messages, so that they will be translatable. Give messages some semblance of conformance to the style guide.
2004-11-29 21:11:06 +01:00
elog(ERROR, "SPI_finish() failed");
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
Fix incorrect tests for undef Perl values in some places in plperl.c. The correct test for defined-ness is SvOK(sv), not anything involving SvTYPE. Per bug #3415 from Matt Taylor. Back-patch as far as 8.0; no apparent problem in 7.x.
2007-06-28 19:49:59 +02:00
if (perlret == NULL || !SvOK(perlret))
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
{
Further plperl cleanup: be more paranoid about checking the type of data returned from Perl. Consolidate multiple bits of code to convert a Perl hash to a tuple, and drive the conversion off the keys present in the hash rather than the tuple column names, so we detect error if the hash contains keys it shouldn't. (This means keys not in the hash will silently default to NULL, which seems ok to me.) Fix a bunch of reference-count leaks too.
2004-11-23 01:21:24 +01:00
/* undef result means go ahead with original tuple */
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
TriggerData *trigdata = ((TriggerData *) fcinfo->context);
if (TRIGGER_FIRED_BY_INSERT(trigdata->tg_event))
retval = (Datum) trigdata->tg_trigtuple;
else if (TRIGGER_FIRED_BY_UPDATE(trigdata->tg_event))
retval = (Datum) trigdata->tg_newtuple;
else if (TRIGGER_FIRED_BY_DELETE(trigdata->tg_event))
retval = (Datum) trigdata->tg_trigtuple;
Support statement-level ON TRUNCATE triggers. Simon Riggs
2008-03-28 01:21:56 +01:00
else if (TRIGGER_FIRED_BY_TRUNCATE(trigdata->tg_event))
retval = (Datum) trigdata->tg_trigtuple;
Remove ill-considered suppression of gcc warnings in plperl, and fix some of the bugs exposed thereby. The remaining 'might be used uninitialized' warnings look like live bugs, but I am not familiar enough with Perl/C hacking to tell how to fix them.
2004-11-17 22:23:36 +01:00
else
retval = (Datum) 0; /* can this happen? */
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
}
else
{
Further plperl cleanup: be more paranoid about checking the type of data returned from Perl. Consolidate multiple bits of code to convert a Perl hash to a tuple, and drive the conversion off the keys present in the hash rather than the tuple column names, so we detect error if the hash contains keys it shouldn't. (This means keys not in the hash will silently default to NULL, which seems ok to me.) Fix a bunch of reference-count leaks too.
2004-11-23 01:21:24 +01:00
HeapTuple trv;
char *tmp;
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
Force strings passed to and from plperl to be in UTF8 encoding. String are converted to UTF8 on the way into perl and to the database encoding on the way back. This avoids a number of observed anomalies, and ensures Perl a consistent view of the world. Some minor code cleanups are also accomplished. Alex Hunsaker, reviewed by Andy Colson.
2011-02-06 23:29:26 +01:00
tmp = sv2cstr(perlret);
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
Further plperl cleanup: be more paranoid about checking the type of data returned from Perl. Consolidate multiple bits of code to convert a Perl hash to a tuple, and drive the conversion off the keys present in the hash rather than the tuple column names, so we detect error if the hash contains keys it shouldn't. (This means keys not in the hash will silently default to NULL, which seems ok to me.) Fix a bunch of reference-count leaks too.
2004-11-23 01:21:24 +01:00
if (pg_strcasecmp(tmp, "SKIP") == 0)
trv = NULL;
else if (pg_strcasecmp(tmp, "MODIFY") == 0)
{
TriggerData *trigdata = (TriggerData *) fcinfo->context;
if (TRIGGER_FIRED_BY_INSERT(trigdata->tg_event))
trv = plperl_modify_tuple(hvTD, trigdata,
trigdata->tg_trigtuple);
else if (TRIGGER_FIRED_BY_UPDATE(trigdata->tg_event))
trv = plperl_modify_tuple(hvTD, trigdata,
trigdata->tg_newtuple);
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
else
{
Update plperl to use ereport() not elog() for user-facing messages, so that they will be translatable. Give messages some semblance of conformance to the style guide.
2004-11-29 21:11:06 +01:00
ereport(WARNING,
(errcode(ERRCODE_E_R_I_E_TRIGGER_PROTOCOL_VIOLATED),
Wordsmithing for PL/Perl messages
2009-02-19 11:33:17 +01:00
errmsg("ignoring modified row in DELETE trigger")));
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
trv = NULL;
}
}
Remove ill-considered suppression of gcc warnings in plperl, and fix some of the bugs exposed thereby. The remaining 'might be used uninitialized' warnings look like live bugs, but I am not familiar enough with Perl/C hacking to tell how to fix them.
2004-11-17 22:23:36 +01:00
else
Further plperl cleanup: be more paranoid about checking the type of data returned from Perl. Consolidate multiple bits of code to convert a Perl hash to a tuple, and drive the conversion off the keys present in the hash rather than the tuple column names, so we detect error if the hash contains keys it shouldn't. (This means keys not in the hash will silently default to NULL, which seems ok to me.) Fix a bunch of reference-count leaks too.
2004-11-23 01:21:24 +01:00
{
Update plperl to use ereport() not elog() for user-facing messages, so that they will be translatable. Give messages some semblance of conformance to the style guide.
2004-11-29 21:11:06 +01:00
ereport(ERROR,
(errcode(ERRCODE_E_R_I_E_TRIGGER_PROTOCOL_VIOLATED),
another small message tweak
2009-02-20 11:39:19 +01:00
errmsg("result of PL/Perl trigger function must be undef, "
Wordsmithing for PL/Perl messages
2009-02-19 11:33:17 +01:00
"\"SKIP\", or \"MODIFY\"")));
Further plperl cleanup: be more paranoid about checking the type of data returned from Perl. Consolidate multiple bits of code to convert a Perl hash to a tuple, and drive the conversion off the keys present in the hash rather than the tuple column names, so we detect error if the hash contains keys it shouldn't. (This means keys not in the hash will silently default to NULL, which seems ok to me.) Fix a bunch of reference-count leaks too.
2004-11-23 01:21:24 +01:00
trv = NULL;
}
retval = PointerGetDatum(trv);
Force strings passed to and from plperl to be in UTF8 encoding. String are converted to UTF8 on the way into perl and to the database encoding on the way back. This avoids a number of observed anomalies, and ensures Perl a consistent view of the world. Some minor code cleanups are also accomplished. Alex Hunsaker, reviewed by Andy Colson.
2011-02-06 23:29:26 +01:00
pfree(tmp);
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
}
errcontext support in PL/Perl Author: Alexey Klyukin <alexk@commandprompt.com>
2009-09-16 08:06:12 +02:00
/* Restore the previous error callback */
error_context_stack = pl_error_context.previous;
PL/Perl portability fix: avoid including XSUB.h in plperl.c. In Perl builds that define PERL_IMPLICIT_SYS, XSUB.h defines macros that replace a whole lot of basic libc functions with Perl functions. We can't tolerate that in plperl.c; it breaks at least PG_TRY and probably other stuff. The core idea of this patch is to include XSUB.h only in the .xs files where it's really needed, and to move any code broken by PERL_IMPLICIT_SYS out of the .xs files and into plperl.c. The reason this hasn't been a problem before is that our build techniques did not result in PERL_IMPLICIT_SYS appearing as a #define in PL/Perl, even on some platforms where Perl thinks it is defined. That's about to change in order to fix a nasty portability issue, so we need this work to make the code safe for that. Rather unaccountably, the Perl people chose XSUB.h as the place to provide the versions of the aTHX/aTHX_ macros that are needed by code that's not explicitly aware of the MULTIPLICITY API conventions. Hence, just removing XSUB.h from plperl.c fails miserably. But we can work around that by defining PERL_NO_GET_CONTEXT (which would make the relevant stanza of XSUB.h a no-op anyway). As explained in perlguts.pod, that means we need to add a "dTHX" macro call in every C function that calls a Perl API function. In most of them we just add this at the top; but since the macro fetches the current Perl interpreter pointer, more care is needed in functions that switch the active interpreter. Lack of the macro is easily recognized since it results in bleats about "my_perl" not being defined. (A nice side benefit of this is that it significantly reduces the number of fetches of the current interpreter pointer. On my machine, plperl.so gets more than 10% smaller, and there's probably some performance win too. We could reduce the number of fetches still more by decorating the code with pTHX_/aTHX_ macros to pass the interpreter pointer around, as explained by perlguts.pod; but that's a task for another day.) Formatting note: pgindent seems happy to treat "dTHX;" as a declaration so long as it's the first thing after the left brace, as we'd already observed with respect to the similar macro "dSP;". If you try to put it later in a set of declarations, pgindent puts ugly extra space around it. Having removed XSUB.h from plperl.c, we need only move the support functions for spi_return_next and util_elog (both of which use PG_TRY) out of the .xs files and into plperl.c. This seems sufficient to avoid the known problems caused by PERL_IMPLICIT_SYS, although we could move more code if additional issues emerge. This will need to be back-patched, but first let's see what the buildfarm makes of it. Patch by me, with some help from Ashutosh Sharma Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
2017-07-28 18:25:43 +02:00
SvREFCNT_dec_current(svTD);
Further plperl cleanup: be more paranoid about checking the type of data returned from Perl. Consolidate multiple bits of code to convert a Perl hash to a tuple, and drive the conversion off the keys present in the hash rather than the tuple column names, so we detect error if the hash contains keys it shouldn't. (This means keys not in the hash will silently default to NULL, which seems ok to me.) Fix a bunch of reference-count leaks too.
2004-11-23 01:21:24 +01:00
if (perlret)
PL/Perl portability fix: avoid including XSUB.h in plperl.c. In Perl builds that define PERL_IMPLICIT_SYS, XSUB.h defines macros that replace a whole lot of basic libc functions with Perl functions. We can't tolerate that in plperl.c; it breaks at least PG_TRY and probably other stuff. The core idea of this patch is to include XSUB.h only in the .xs files where it's really needed, and to move any code broken by PERL_IMPLICIT_SYS out of the .xs files and into plperl.c. The reason this hasn't been a problem before is that our build techniques did not result in PERL_IMPLICIT_SYS appearing as a #define in PL/Perl, even on some platforms where Perl thinks it is defined. That's about to change in order to fix a nasty portability issue, so we need this work to make the code safe for that. Rather unaccountably, the Perl people chose XSUB.h as the place to provide the versions of the aTHX/aTHX_ macros that are needed by code that's not explicitly aware of the MULTIPLICITY API conventions. Hence, just removing XSUB.h from plperl.c fails miserably. But we can work around that by defining PERL_NO_GET_CONTEXT (which would make the relevant stanza of XSUB.h a no-op anyway). As explained in perlguts.pod, that means we need to add a "dTHX" macro call in every C function that calls a Perl API function. In most of them we just add this at the top; but since the macro fetches the current Perl interpreter pointer, more care is needed in functions that switch the active interpreter. Lack of the macro is easily recognized since it results in bleats about "my_perl" not being defined. (A nice side benefit of this is that it significantly reduces the number of fetches of the current interpreter pointer. On my machine, plperl.so gets more than 10% smaller, and there's probably some performance win too. We could reduce the number of fetches still more by decorating the code with pTHX_/aTHX_ macros to pass the interpreter pointer around, as explained by perlguts.pod; but that's a task for another day.) Formatting note: pgindent seems happy to treat "dTHX;" as a declaration so long as it's the first thing after the left brace, as we'd already observed with respect to the similar macro "dSP;". If you try to put it later in a set of declarations, pgindent puts ugly extra space around it. Having removed XSUB.h from plperl.c, we need only move the support functions for spi_return_next and util_elog (both of which use PG_TRY) out of the .xs files and into plperl.c. This seems sufficient to avoid the known problems caused by PERL_IMPLICIT_SYS, although we could move more code if additional issues emerge. This will need to be back-patched, but first let's see what the buildfarm makes of it. Patch by me, with some help from Ashutosh Sharma Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
2017-07-28 18:25:43 +02:00
SvREFCNT_dec_current(perlret);
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
return retval;
}
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
At 2005-05-21 20:18:50 +0530, ams@oryx.com wrote: > > > The second issue is where plperl returns a large result set. I have attached the following seven patches to address this problem: 1. Trivial. Replaces some errant spaces with tabs. 2. Trivial. Fixes the spelling of Jan's name, and gets rid of many inane, useless, annoying, and often misleading comments. Here's a sample: "plperl_init_all() - Initialize all". (I have tried to add some useful comments here and there, and will continue to do so now and again.) 3. Trivial. Splits up some long lines. 4. Converts SRFs in PL/Perl to use a Tuplestore and SFRM_Materialize to return the result set, based on the PL/PgSQL model. There are two major consequences: result sets will spill to disk when they can no longer fit in work_mem; and "select foo_srf()" no longer works. (I didn't lose sleep over the latter, since that form is not valid in PL/PgSQL, and it's not documented in PL/Perl.) 5. Trivial, but important. Fixes use of "undef" instead of undef. This would cause empty functions to fail in bizarre ways. I suspect that there's still another (old) bug here. I'll investigate further. 6. Moves the majority of (4) out into a new plperl_return_next() function, to make it possible to expose the functionality to Perl; cleans up some of the code besides. 7. Add an spi_return_next function for use in Perl code. If you want to apply the patches and try them out, 8-composite.diff is what you should use. (Note: my patches depend upon Andrew's use-strict and %_SHARED patches being applied.) Here's something to try: create or replace function foo() returns setof record as $$ $i = 0; for ("World", "PostgreSQL", "PL/Perl") { spi_return_next({f1=>++$i, f2=>'Hello', f3=>$_}); } return; $$ language plperl; select * from foo() as (f1 integer, f2 text, f3 text); (Many thanks to Andrews Dunstan and Supernews for their help.) Abhijit Menon-Sen
2005-06-04 22:33:06 +02:00
PL/Perl: Add event trigger support From: Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2013-12-11 14:11:59 +01:00
static void
plperl_event_trigger_handler(PG_FUNCTION_ARGS)
{
plperl_proc_desc *prodesc;
SV *svTD;
ErrorContextCallback pl_error_context;
/* Connect to SPI manager */
if (SPI_connect() != SPI_OK_CONNECT)
elog(ERROR, "could not connect to SPI manager");
/* Find or compile the function */
prodesc = compile_plperl_function(fcinfo->flinfo->fn_oid, false, true);
current_call_data->prodesc = prodesc;
increment_prodesc_refcount(prodesc);
/* Set a callback for error reporting */
pl_error_context.callback = plperl_exec_callback;
pl_error_context.previous = error_context_stack;
pl_error_context.arg = prodesc->proname;
error_context_stack = &pl_error_context;
activate_interpreter(prodesc->interp);
svTD = plperl_event_trigger_build_args(fcinfo);
plperl_call_perl_event_trigger_func(prodesc, fcinfo, svTD);
if (SPI_finish() != SPI_OK_FINISH)
elog(ERROR, "SPI_finish() failed");
/* Restore the previous error callback */
error_context_stack = pl_error_context.previous;
PL/Perl portability fix: avoid including XSUB.h in plperl.c. In Perl builds that define PERL_IMPLICIT_SYS, XSUB.h defines macros that replace a whole lot of basic libc functions with Perl functions. We can't tolerate that in plperl.c; it breaks at least PG_TRY and probably other stuff. The core idea of this patch is to include XSUB.h only in the .xs files where it's really needed, and to move any code broken by PERL_IMPLICIT_SYS out of the .xs files and into plperl.c. The reason this hasn't been a problem before is that our build techniques did not result in PERL_IMPLICIT_SYS appearing as a #define in PL/Perl, even on some platforms where Perl thinks it is defined. That's about to change in order to fix a nasty portability issue, so we need this work to make the code safe for that. Rather unaccountably, the Perl people chose XSUB.h as the place to provide the versions of the aTHX/aTHX_ macros that are needed by code that's not explicitly aware of the MULTIPLICITY API conventions. Hence, just removing XSUB.h from plperl.c fails miserably. But we can work around that by defining PERL_NO_GET_CONTEXT (which would make the relevant stanza of XSUB.h a no-op anyway). As explained in perlguts.pod, that means we need to add a "dTHX" macro call in every C function that calls a Perl API function. In most of them we just add this at the top; but since the macro fetches the current Perl interpreter pointer, more care is needed in functions that switch the active interpreter. Lack of the macro is easily recognized since it results in bleats about "my_perl" not being defined. (A nice side benefit of this is that it significantly reduces the number of fetches of the current interpreter pointer. On my machine, plperl.so gets more than 10% smaller, and there's probably some performance win too. We could reduce the number of fetches still more by decorating the code with pTHX_/aTHX_ macros to pass the interpreter pointer around, as explained by perlguts.pod; but that's a task for another day.) Formatting note: pgindent seems happy to treat "dTHX;" as a declaration so long as it's the first thing after the left brace, as we'd already observed with respect to the similar macro "dSP;". If you try to put it later in a set of declarations, pgindent puts ugly extra space around it. Having removed XSUB.h from plperl.c, we need only move the support functions for spi_return_next and util_elog (both of which use PG_TRY) out of the .xs files and into plperl.c. This seems sufficient to avoid the known problems caused by PERL_IMPLICIT_SYS, although we could move more code if additional issues emerge. This will need to be back-patched, but first let's see what the buildfarm makes of it. Patch by me, with some help from Ashutosh Sharma Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
2017-07-28 18:25:43 +02:00
SvREFCNT_dec_current(svTD);
PL/Perl: Add event trigger support From: Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2013-12-11 14:11:59 +01:00
}
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
static bool
validate_plperl_function(plperl_proc_ptr *proc_ptr, HeapTuple procTup)
{
if (proc_ptr && proc_ptr->proc_ptr)
{
plperl_proc_desc *prodesc = proc_ptr->proc_ptr;
bool uptodate;
/************************************************************
* If it's present, must check whether it's still up to date.
* This is needed because CREATE OR REPLACE FUNCTION can modify the
* function's pg_proc entry without changing its OID.
************************************************************/
Change the way we mark tuples as frozen. Instead of changing the tuple xmin to FrozenTransactionId, the combination of HEAP_XMIN_COMMITTED and HEAP_XMIN_INVALID, which were previously never set together, is now defined as HEAP_XMIN_FROZEN. A variety of previous proposals to freeze tuples opportunistically before vacuum_freeze_min_age is reached have foundered on the objection that replacing xmin by FrozenTransactionId might hinder debugging efforts when things in this area go awry; this patch is intended to solve that problem by keeping the XID around (but largely ignoring the value to which it is set). Third-party code that checks for HEAP_XMIN_INVALID on tuples where HEAP_XMIN_COMMITTED might be set will be broken by this change. To fix, use the new accessor macros in htup_details.h rather than consulting the bits directly. HeapTupleHeaderGetXmin has been modified to return FrozenTransactionId when the infomask bits indicate that the tuple is frozen; use HeapTupleHeaderGetRawXmin when you already know that the tuple isn't marked commited or frozen, or want the raw value anyway. We currently do this in routines that display the xmin for user consumption, in tqual.c where it's known to be safe and important for the avoidance of extra cycles, and in the function-caching code for various procedural languages, which shouldn't invalidate the cache just because the tuple gets frozen. Robert Haas and Andres Freund
2013-12-22 21:49:09 +01:00
uptodate = (prodesc->fn_xmin == HeapTupleHeaderGetRawXmin(procTup->t_data) &&
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
ItemPointerEquals(&prodesc->fn_tid, &procTup->t_self));
if (uptodate)
return true;
/* Otherwise, unlink the obsoleted entry from the hashtable ... */
proc_ptr->proc_ptr = NULL;
Make plperl safe against functions that are redefined while running. validate_plperl_function() supposed that it could free an old plperl_proc_desc struct immediately upon detecting that it was stale. However, if a plperl function is called recursively, this could result in deleting the struct out from under an outer invocation, leading to misbehavior or crashes. Add a simple reference-count mechanism to ensure that such structs are freed only when the last reference goes away. Per investigation of bug #7516 from Marko Tiikkaja. I am not certain that this error explains his report, because he says he didn't have any recursive calls --- but it's hard to see how else it could have crashed right there. In any case, this definitely fixes some problems in the area. Back-patch to all active branches.
2012-09-10 02:32:54 +02:00
/* ... and release the corresponding refcount, probably deleting it */
decrement_prodesc_refcount(prodesc);
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
}
return false;
}
Make plperl safe against functions that are redefined while running. validate_plperl_function() supposed that it could free an old plperl_proc_desc struct immediately upon detecting that it was stale. However, if a plperl function is called recursively, this could result in deleting the struct out from under an outer invocation, leading to misbehavior or crashes. Add a simple reference-count mechanism to ensure that such structs are freed only when the last reference goes away. Per investigation of bug #7516 from Marko Tiikkaja. I am not certain that this error explains his report, because he says he didn't have any recursive calls --- but it's hard to see how else it could have crashed right there. In any case, this definitely fixes some problems in the area. Back-patch to all active branches.
2012-09-10 02:32:54 +02:00
static void
free_plperl_function(plperl_proc_desc *prodesc)
{
Improve memory management for PL/Perl functions. Unlike PL/Tcl, PL/Perl at least made an attempt to clean up after itself when a function gets redefined. But it was still using TopMemoryContext for the fn_mcxt of argument/result I/O functions, resulting in the potential for memory leaks depending on what those functions did, and the retail alloc/free logic was pretty bulky as well. Fix things to use a per-function memory context like the other PLs now do. Tweak a couple of places where things were being done in a not-very-safe order (on the principle that a memory leak is better than leaving global state inconsistent after an error). Also make some minor cosmetic adjustments, mostly in field names, to make the code look similar to the way PL/Tcl does now wherever it's essentially the same logic. Michael Paquier and Tom Lane Discussion: <CAB7nPqSOyAsHC6jL24J1B+oK3p=yyNoFU0Vs_B6fd2kdd5g5WQ@mail.gmail.com>
2016-09-01 01:54:58 +02:00
Assert(prodesc->fn_refcount == 0);
Make plperl safe against functions that are redefined while running. validate_plperl_function() supposed that it could free an old plperl_proc_desc struct immediately upon detecting that it was stale. However, if a plperl function is called recursively, this could result in deleting the struct out from under an outer invocation, leading to misbehavior or crashes. Add a simple reference-count mechanism to ensure that such structs are freed only when the last reference goes away. Per investigation of bug #7516 from Marko Tiikkaja. I am not certain that this error explains his report, because he says he didn't have any recursive calls --- but it's hard to see how else it could have crashed right there. In any case, this definitely fixes some problems in the area. Back-patch to all active branches.
2012-09-10 02:32:54 +02:00
/* Release CODE reference, if we have one, from the appropriate interp */
if (prodesc->reference)
{
plperl_interp_desc *oldinterp = plperl_active_interp;
activate_interpreter(prodesc->interp);
PL/Perl portability fix: avoid including XSUB.h in plperl.c. In Perl builds that define PERL_IMPLICIT_SYS, XSUB.h defines macros that replace a whole lot of basic libc functions with Perl functions. We can't tolerate that in plperl.c; it breaks at least PG_TRY and probably other stuff. The core idea of this patch is to include XSUB.h only in the .xs files where it's really needed, and to move any code broken by PERL_IMPLICIT_SYS out of the .xs files and into plperl.c. The reason this hasn't been a problem before is that our build techniques did not result in PERL_IMPLICIT_SYS appearing as a #define in PL/Perl, even on some platforms where Perl thinks it is defined. That's about to change in order to fix a nasty portability issue, so we need this work to make the code safe for that. Rather unaccountably, the Perl people chose XSUB.h as the place to provide the versions of the aTHX/aTHX_ macros that are needed by code that's not explicitly aware of the MULTIPLICITY API conventions. Hence, just removing XSUB.h from plperl.c fails miserably. But we can work around that by defining PERL_NO_GET_CONTEXT (which would make the relevant stanza of XSUB.h a no-op anyway). As explained in perlguts.pod, that means we need to add a "dTHX" macro call in every C function that calls a Perl API function. In most of them we just add this at the top; but since the macro fetches the current Perl interpreter pointer, more care is needed in functions that switch the active interpreter. Lack of the macro is easily recognized since it results in bleats about "my_perl" not being defined. (A nice side benefit of this is that it significantly reduces the number of fetches of the current interpreter pointer. On my machine, plperl.so gets more than 10% smaller, and there's probably some performance win too. We could reduce the number of fetches still more by decorating the code with pTHX_/aTHX_ macros to pass the interpreter pointer around, as explained by perlguts.pod; but that's a task for another day.) Formatting note: pgindent seems happy to treat "dTHX;" as a declaration so long as it's the first thing after the left brace, as we'd already observed with respect to the similar macro "dSP;". If you try to put it later in a set of declarations, pgindent puts ugly extra space around it. Having removed XSUB.h from plperl.c, we need only move the support functions for spi_return_next and util_elog (both of which use PG_TRY) out of the .xs files and into plperl.c. This seems sufficient to avoid the known problems caused by PERL_IMPLICIT_SYS, although we could move more code if additional issues emerge. This will need to be back-patched, but first let's see what the buildfarm makes of it. Patch by me, with some help from Ashutosh Sharma Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
2017-07-28 18:25:43 +02:00
SvREFCNT_dec_current(prodesc->reference);
Make plperl safe against functions that are redefined while running. validate_plperl_function() supposed that it could free an old plperl_proc_desc struct immediately upon detecting that it was stale. However, if a plperl function is called recursively, this could result in deleting the struct out from under an outer invocation, leading to misbehavior or crashes. Add a simple reference-count mechanism to ensure that such structs are freed only when the last reference goes away. Per investigation of bug #7516 from Marko Tiikkaja. I am not certain that this error explains his report, because he says he didn't have any recursive calls --- but it's hard to see how else it could have crashed right there. In any case, this definitely fixes some problems in the area. Back-patch to all active branches.
2012-09-10 02:32:54 +02:00
activate_interpreter(oldinterp);
}
Improve memory management for PL/Perl functions. Unlike PL/Tcl, PL/Perl at least made an attempt to clean up after itself when a function gets redefined. But it was still using TopMemoryContext for the fn_mcxt of argument/result I/O functions, resulting in the potential for memory leaks depending on what those functions did, and the retail alloc/free logic was pretty bulky as well. Fix things to use a per-function memory context like the other PLs now do. Tweak a couple of places where things were being done in a not-very-safe order (on the principle that a memory leak is better than leaving global state inconsistent after an error). Also make some minor cosmetic adjustments, mostly in field names, to make the code look similar to the way PL/Tcl does now wherever it's essentially the same logic. Michael Paquier and Tom Lane Discussion: <CAB7nPqSOyAsHC6jL24J1B+oK3p=yyNoFU0Vs_B6fd2kdd5g5WQ@mail.gmail.com>
2016-09-01 01:54:58 +02:00
/* Release all PG-owned data for this proc */
MemoryContextDelete(prodesc->fn_cxt);
Make plperl safe against functions that are redefined while running. validate_plperl_function() supposed that it could free an old plperl_proc_desc struct immediately upon detecting that it was stale. However, if a plperl function is called recursively, this could result in deleting the struct out from under an outer invocation, leading to misbehavior or crashes. Add a simple reference-count mechanism to ensure that such structs are freed only when the last reference goes away. Per investigation of bug #7516 from Marko Tiikkaja. I am not certain that this error explains his report, because he says he didn't have any recursive calls --- but it's hard to see how else it could have crashed right there. In any case, this definitely fixes some problems in the area. Back-patch to all active branches.
2012-09-10 02:32:54 +02:00
}
Fix plperl to discard cached function definition after CREATE OR REPLACE FUNCTION. Clean up typlen/typmod errors inherited from pltcl.
2001-10-20 00:43:49 +02:00
static plperl_proc_desc *
PL/Perl: Add event trigger support From: Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2013-12-11 14:11:59 +01:00
compile_plperl_function(Oid fn_oid, bool is_trigger, bool is_event_trigger)
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
{
Fix plperl to discard cached function definition after CREATE OR REPLACE FUNCTION. Clean up typlen/typmod errors inherited from pltcl.
2001-10-20 00:43:49 +02:00
HeapTuple procTup;
Form_pg_proc procStruct;
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
plperl_proc_key proc_key;
plperl_proc_ptr *proc_ptr;
Improve memory management for PL/Perl functions. Unlike PL/Tcl, PL/Perl at least made an attempt to clean up after itself when a function gets redefined. But it was still using TopMemoryContext for the fn_mcxt of argument/result I/O functions, resulting in the potential for memory leaks depending on what those functions did, and the retail alloc/free logic was pretty bulky as well. Fix things to use a per-function memory context like the other PLs now do. Tweak a couple of places where things were being done in a not-very-safe order (on the principle that a memory leak is better than leaving global state inconsistent after an error). Also make some minor cosmetic adjustments, mostly in field names, to make the code look similar to the way PL/Tcl does now wherever it's essentially the same logic. Michael Paquier and Tom Lane Discussion: <CAB7nPqSOyAsHC6jL24J1B+oK3p=yyNoFU0Vs_B6fd2kdd5g5WQ@mail.gmail.com>
2016-09-01 01:54:58 +02:00
plperl_proc_desc *volatile prodesc = NULL;
volatile MemoryContext proc_cxt = NULL;
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
plperl_interp_desc *oldinterp = plperl_active_interp;
errcontext support in PL/Perl Author: Alexey Klyukin <alexk@commandprompt.com>
2009-09-16 08:06:12 +02:00
ErrorContextCallback plperl_error_context;
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
Fix plperl to discard cached function definition after CREATE OR REPLACE FUNCTION. Clean up typlen/typmod errors inherited from pltcl.
2001-10-20 00:43:49 +02:00
/* We'll need the pg_proc tuple in any case... */
Wrap calls to SearchSysCache and related functions using macros. The purpose of this change is to eliminate the need for every caller of SearchSysCache, SearchSysCacheCopy, SearchSysCacheExists, GetSysCacheOid, and SearchSysCacheList to know the maximum number of allowable keys for a syscache entry (currently 4). This will make it far easier to increase the maximum number of keys in a future release should we choose to do so, and it makes the code shorter, too. Design and review by Tom Lane.
2010-02-14 19:42:19 +01:00
procTup = SearchSysCache1(PROCOID, ObjectIdGetDatum(fn_oid));
Fix plperl to discard cached function definition after CREATE OR REPLACE FUNCTION. Clean up typlen/typmod errors inherited from pltcl.
2001-10-20 00:43:49 +02:00
if (!HeapTupleIsValid(procTup))
Error message editing in src/pl. The plpython module could use another look ... I'm not real certain which errors are strictly internal and which are likely to be provoked by users.
2003-07-26 01:37:31 +02:00
elog(ERROR, "cache lookup failed for function %u", fn_oid);
Fix plperl to discard cached function definition after CREATE OR REPLACE FUNCTION. Clean up typlen/typmod errors inherited from pltcl.
2001-10-20 00:43:49 +02:00
procStruct = (Form_pg_proc) GETSTRUCT(procTup);
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
Improve memory management for PL/Perl functions. Unlike PL/Tcl, PL/Perl at least made an attempt to clean up after itself when a function gets redefined. But it was still using TopMemoryContext for the fn_mcxt of argument/result I/O functions, resulting in the potential for memory leaks depending on what those functions did, and the retail alloc/free logic was pretty bulky as well. Fix things to use a per-function memory context like the other PLs now do. Tweak a couple of places where things were being done in a not-very-safe order (on the principle that a memory leak is better than leaving global state inconsistent after an error). Also make some minor cosmetic adjustments, mostly in field names, to make the code look similar to the way PL/Tcl does now wherever it's essentially the same logic. Michael Paquier and Tom Lane Discussion: <CAB7nPqSOyAsHC6jL24J1B+oK3p=yyNoFU0Vs_B6fd2kdd5g5WQ@mail.gmail.com>
2016-09-01 01:54:58 +02:00
/*
* Try to find function in plperl_proc_hash. The reason for this
* overcomplicated-seeming lookup procedure is that we don't know whether
* it's plperl or plperlu, and don't want to spend a lookup in pg_language
* to find out.
*/
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
proc_key.proc_id = fn_oid;
Revert removal of trigger flag from plperl function hash key. As noted by Jan Urbanski, this flag is in fact needed to ensure that the function's input/result conversion functions are set up as expected. Add a regression test to discourage anyone from making same mistake in future.
2010-10-31 16:42:51 +01:00
proc_key.is_trigger = is_trigger;
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
proc_key.user_id = GetUserId();
proc_ptr = hash_search(plperl_proc_hash, &proc_key,
HASH_FIND, NULL);
Improve memory management for PL/Perl functions. Unlike PL/Tcl, PL/Perl at least made an attempt to clean up after itself when a function gets redefined. But it was still using TopMemoryContext for the fn_mcxt of argument/result I/O functions, resulting in the potential for memory leaks depending on what those functions did, and the retail alloc/free logic was pretty bulky as well. Fix things to use a per-function memory context like the other PLs now do. Tweak a couple of places where things were being done in a not-very-safe order (on the principle that a memory leak is better than leaving global state inconsistent after an error). Also make some minor cosmetic adjustments, mostly in field names, to make the code look similar to the way PL/Tcl does now wherever it's essentially the same logic. Michael Paquier and Tom Lane Discussion: <CAB7nPqSOyAsHC6jL24J1B+oK3p=yyNoFU0Vs_B6fd2kdd5g5WQ@mail.gmail.com>
2016-09-01 01:54:58 +02:00
if (validate_plperl_function(proc_ptr, procTup))
{
/* Found valid plperl entry */
ReleaseSysCache(procTup);
return proc_ptr->proc_ptr;
}
Force plperl and plperlu to run in separate interpreters. Create an error on an attempt to create the second interpreter if this is not supported by the perl installation. Per recent -hackers discussion.
2006-11-13 18:13:57 +01:00
Improve memory management for PL/Perl functions. Unlike PL/Tcl, PL/Perl at least made an attempt to clean up after itself when a function gets redefined. But it was still using TopMemoryContext for the fn_mcxt of argument/result I/O functions, resulting in the potential for memory leaks depending on what those functions did, and the retail alloc/free logic was pretty bulky as well. Fix things to use a per-function memory context like the other PLs now do. Tweak a couple of places where things were being done in a not-very-safe order (on the principle that a memory leak is better than leaving global state inconsistent after an error). Also make some minor cosmetic adjustments, mostly in field names, to make the code look similar to the way PL/Tcl does now wherever it's essentially the same logic. Michael Paquier and Tom Lane Discussion: <CAB7nPqSOyAsHC6jL24J1B+oK3p=yyNoFU0Vs_B6fd2kdd5g5WQ@mail.gmail.com>
2016-09-01 01:54:58 +02:00
/* If not found or obsolete, maybe it's plperlu */
proc_key.user_id = InvalidOid;
proc_ptr = hash_search(plperl_proc_hash, &proc_key,
HASH_FIND, NULL);
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
if (validate_plperl_function(proc_ptr, procTup))
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
{
Improve memory management for PL/Perl functions. Unlike PL/Tcl, PL/Perl at least made an attempt to clean up after itself when a function gets redefined. But it was still using TopMemoryContext for the fn_mcxt of argument/result I/O functions, resulting in the potential for memory leaks depending on what those functions did, and the retail alloc/free logic was pretty bulky as well. Fix things to use a per-function memory context like the other PLs now do. Tweak a couple of places where things were being done in a not-very-safe order (on the principle that a memory leak is better than leaving global state inconsistent after an error). Also make some minor cosmetic adjustments, mostly in field names, to make the code look similar to the way PL/Tcl does now wherever it's essentially the same logic. Michael Paquier and Tom Lane Discussion: <CAB7nPqSOyAsHC6jL24J1B+oK3p=yyNoFU0Vs_B6fd2kdd5g5WQ@mail.gmail.com>
2016-09-01 01:54:58 +02:00
/* Found valid plperlu entry */
ReleaseSysCache(procTup);
return proc_ptr->proc_ptr;
Fix plperl to discard cached function definition after CREATE OR REPLACE FUNCTION. Clean up typlen/typmod errors inherited from pltcl.
2001-10-20 00:43:49 +02:00
}
/************************************************************
* If we haven't found it in the hashtable, we analyze
Fix a few minor typos in comments in PL/Perl.
2006-02-26 23:26:39 +01:00
* the function's arguments and return type and store
Improve memory management for PL/Perl functions. Unlike PL/Tcl, PL/Perl at least made an attempt to clean up after itself when a function gets redefined. But it was still using TopMemoryContext for the fn_mcxt of argument/result I/O functions, resulting in the potential for memory leaks depending on what those functions did, and the retail alloc/free logic was pretty bulky as well. Fix things to use a per-function memory context like the other PLs now do. Tweak a couple of places where things were being done in a not-very-safe order (on the principle that a memory leak is better than leaving global state inconsistent after an error). Also make some minor cosmetic adjustments, mostly in field names, to make the code look similar to the way PL/Tcl does now wherever it's essentially the same logic. Michael Paquier and Tom Lane Discussion: <CAB7nPqSOyAsHC6jL24J1B+oK3p=yyNoFU0Vs_B6fd2kdd5g5WQ@mail.gmail.com>
2016-09-01 01:54:58 +02:00
* the in-/out-functions in the prodesc block,
* then we load the procedure into the Perl interpreter,
* and last we create a new hashtable entry for it.
Fix plperl to discard cached function definition after CREATE OR REPLACE FUNCTION. Clean up typlen/typmod errors inherited from pltcl.
2001-10-20 00:43:49 +02:00
************************************************************/
Improve memory management for PL/Perl functions. Unlike PL/Tcl, PL/Perl at least made an attempt to clean up after itself when a function gets redefined. But it was still using TopMemoryContext for the fn_mcxt of argument/result I/O functions, resulting in the potential for memory leaks depending on what those functions did, and the retail alloc/free logic was pretty bulky as well. Fix things to use a per-function memory context like the other PLs now do. Tweak a couple of places where things were being done in a not-very-safe order (on the principle that a memory leak is better than leaving global state inconsistent after an error). Also make some minor cosmetic adjustments, mostly in field names, to make the code look similar to the way PL/Tcl does now wherever it's essentially the same logic. Michael Paquier and Tom Lane Discussion: <CAB7nPqSOyAsHC6jL24J1B+oK3p=yyNoFU0Vs_B6fd2kdd5g5WQ@mail.gmail.com>
2016-09-01 01:54:58 +02:00
/* Set a callback for reporting compilation errors */
plperl_error_context.callback = plperl_compile_callback;
plperl_error_context.previous = error_context_stack;
plperl_error_context.arg = NameStr(procStruct->proname);
error_context_stack = &plperl_error_context;
PG_TRY();
Fix plperl to discard cached function definition after CREATE OR REPLACE FUNCTION. Clean up typlen/typmod errors inherited from pltcl.
2001-10-20 00:43:49 +02:00
{
HeapTuple langTup;
HeapTuple typeTup;
Form_pg_language langStruct;
Form_pg_type typeStruct;
Add transforms feature This provides a mechanism for specifying conversions between SQL data types and procedural languages. As examples, there are transforms for hstore and ltree for PL/Perl and PL/Python. reviews by Pavel Stěhule and Andres Freund
2015-04-26 16:33:14 +02:00
Datum protrftypes_datum;
Apply the core parts of Dennis Bjorklund's patch to allow function parameters to be declared with names. pg_proc has a column to store names, and CREATE FUNCTION can insert data into it, but that's all as yet. I need to do more work on the pg_dump and plpgsql portions of the patch before committing those, but I thought I'd get the bulky changes in before the tree drifts under me. initdb forced due to pg_proc change.
2004-01-07 00:55:19 +01:00
Datum prosrcdatum;
bool isnull;
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
char *proc_source;
Improve memory management for PL/Perl functions. Unlike PL/Tcl, PL/Perl at least made an attempt to clean up after itself when a function gets redefined. But it was still using TopMemoryContext for the fn_mcxt of argument/result I/O functions, resulting in the potential for memory leaks depending on what those functions did, and the retail alloc/free logic was pretty bulky as well. Fix things to use a per-function memory context like the other PLs now do. Tweak a couple of places where things were being done in a not-very-safe order (on the principle that a memory leak is better than leaving global state inconsistent after an error). Also make some minor cosmetic adjustments, mostly in field names, to make the code look similar to the way PL/Tcl does now wherever it's essentially the same logic. Michael Paquier and Tom Lane Discussion: <CAB7nPqSOyAsHC6jL24J1B+oK3p=yyNoFU0Vs_B6fd2kdd5g5WQ@mail.gmail.com>
2016-09-01 01:54:58 +02:00
MemoryContext oldcontext;
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
/************************************************************
Improve memory management for PL/Perl functions. Unlike PL/Tcl, PL/Perl at least made an attempt to clean up after itself when a function gets redefined. But it was still using TopMemoryContext for the fn_mcxt of argument/result I/O functions, resulting in the potential for memory leaks depending on what those functions did, and the retail alloc/free logic was pretty bulky as well. Fix things to use a per-function memory context like the other PLs now do. Tweak a couple of places where things were being done in a not-very-safe order (on the principle that a memory leak is better than leaving global state inconsistent after an error). Also make some minor cosmetic adjustments, mostly in field names, to make the code look similar to the way PL/Tcl does now wherever it's essentially the same logic. Michael Paquier and Tom Lane Discussion: <CAB7nPqSOyAsHC6jL24J1B+oK3p=yyNoFU0Vs_B6fd2kdd5g5WQ@mail.gmail.com>
2016-09-01 01:54:58 +02:00
* Allocate a context that will hold all PG data for the procedure.
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
************************************************************/
Allow memory contexts to have both fixed and variable ident strings. Originally, we treated memory context names as potentially variable in all cases, and therefore always copied them into the context header. Commit 9fa6f00b1 rethought this a little bit and invented a distinction between fixed and variable names, skipping the copy step for the former. But we can make things both simpler and more useful by instead allowing there to be two parts to a context's identification, a fixed "name" and an optional, variable "ident". The name supplied in the context create call is now required to be a compile-time-constant string in all cases, as it is never copied but just pointed to. The "ident" string, if wanted, is supplied later. This is needed because typically we want the ident to be stored inside the context so that it's cleaned up automatically on context deletion; that means it has to be copied into the context before we can set the pointer. The cost of this approach is basically just an additional pointer field in struct MemoryContextData, which isn't much overhead, and is bought back entirely in the AllocSet case by not needing a headerSize field anymore, since we no longer have to cope with variable header length. In addition, we can simplify the internal interfaces for memory context creation still further, saving a few cycles there. And it's no longer true that a custom identifier disqualifies a context from participating in aset.c's freelist scheme, so possibly there's some win on that end. All the places that were using non-compile-time-constant context names are adjusted to put the variable info into the "ident" instead. This allows more effective identification of those contexts in many cases; for example, subsidary contexts of relcache entries are now identified by both type (e.g. "index info") and relname, where before you got only one or the other. Contexts associated with PL function cache entries are now identified more fully and uniformly, too. I also arranged for plancache contexts to use the query source string as their identifier. This is basically free for CachedPlanSources, as they contained a copy of that string already. We pay an extra pstrdup to do it for CachedPlans. That could perhaps be avoided, but it would make things more fragile (since the CachedPlanSource is sometimes destroyed first). I suspect future improvements in error reporting will require CachedPlans to have a copy of that string anyway, so it's not clear that it's worth moving mountains to avoid it now. This also changes the APIs for context statistics routines so that the context-specific routines no longer assume that output goes straight to stderr, nor do they know all details of the output format. This is useful immediately to reduce code duplication, and it also allows for external code to do something with stats output that's different from printing to stderr. The reason for pushing this now rather than waiting for v12 is that it rethinks some of the API changes made by commit 9fa6f00b1. Seems better for extension authors to endure just one round of API changes not two. Discussion: https://postgr.es/m/CAB=Je-FdtmFZ9y9REHD7VsSrnCkiBhsA4mdsLKSPauwXtQBeNA@mail.gmail.com
2018-03-27 22:46:47 +02:00
proc_cxt = AllocSetContextCreate(TopMemoryContext,
"PL/Perl function",
ALLOCSET_SMALL_SIZES);
Make plperl safe against functions that are redefined while running. validate_plperl_function() supposed that it could free an old plperl_proc_desc struct immediately upon detecting that it was stale. However, if a plperl function is called recursively, this could result in deleting the struct out from under an outer invocation, leading to misbehavior or crashes. Add a simple reference-count mechanism to ensure that such structs are freed only when the last reference goes away. Per investigation of bug #7516 from Marko Tiikkaja. I am not certain that this error explains his report, because he says he didn't have any recursive calls --- but it's hard to see how else it could have crashed right there. In any case, this definitely fixes some problems in the area. Back-patch to all active branches.
2012-09-10 02:32:54 +02:00
Improve memory management for PL/Perl functions. Unlike PL/Tcl, PL/Perl at least made an attempt to clean up after itself when a function gets redefined. But it was still using TopMemoryContext for the fn_mcxt of argument/result I/O functions, resulting in the potential for memory leaks depending on what those functions did, and the retail alloc/free logic was pretty bulky as well. Fix things to use a per-function memory context like the other PLs now do. Tweak a couple of places where things were being done in a not-very-safe order (on the principle that a memory leak is better than leaving global state inconsistent after an error). Also make some minor cosmetic adjustments, mostly in field names, to make the code look similar to the way PL/Tcl does now wherever it's essentially the same logic. Michael Paquier and Tom Lane Discussion: <CAB7nPqSOyAsHC6jL24J1B+oK3p=yyNoFU0Vs_B6fd2kdd5g5WQ@mail.gmail.com>
2016-09-01 01:54:58 +02:00
/************************************************************
* Allocate and fill a new procedure description block.
* struct prodesc and subsidiary data must all live in proc_cxt.
************************************************************/
oldcontext = MemoryContextSwitchTo(proc_cxt);
prodesc = (plperl_proc_desc *) palloc0(sizeof(plperl_proc_desc));
prodesc->proname = pstrdup(NameStr(procStruct->proname));
Allow memory contexts to have both fixed and variable ident strings. Originally, we treated memory context names as potentially variable in all cases, and therefore always copied them into the context header. Commit 9fa6f00b1 rethought this a little bit and invented a distinction between fixed and variable names, skipping the copy step for the former. But we can make things both simpler and more useful by instead allowing there to be two parts to a context's identification, a fixed "name" and an optional, variable "ident". The name supplied in the context create call is now required to be a compile-time-constant string in all cases, as it is never copied but just pointed to. The "ident" string, if wanted, is supplied later. This is needed because typically we want the ident to be stored inside the context so that it's cleaned up automatically on context deletion; that means it has to be copied into the context before we can set the pointer. The cost of this approach is basically just an additional pointer field in struct MemoryContextData, which isn't much overhead, and is bought back entirely in the AllocSet case by not needing a headerSize field anymore, since we no longer have to cope with variable header length. In addition, we can simplify the internal interfaces for memory context creation still further, saving a few cycles there. And it's no longer true that a custom identifier disqualifies a context from participating in aset.c's freelist scheme, so possibly there's some win on that end. All the places that were using non-compile-time-constant context names are adjusted to put the variable info into the "ident" instead. This allows more effective identification of those contexts in many cases; for example, subsidary contexts of relcache entries are now identified by both type (e.g. "index info") and relname, where before you got only one or the other. Contexts associated with PL function cache entries are now identified more fully and uniformly, too. I also arranged for plancache contexts to use the query source string as their identifier. This is basically free for CachedPlanSources, as they contained a copy of that string already. We pay an extra pstrdup to do it for CachedPlans. That could perhaps be avoided, but it would make things more fragile (since the CachedPlanSource is sometimes destroyed first). I suspect future improvements in error reporting will require CachedPlans to have a copy of that string anyway, so it's not clear that it's worth moving mountains to avoid it now. This also changes the APIs for context statistics routines so that the context-specific routines no longer assume that output goes straight to stderr, nor do they know all details of the output format. This is useful immediately to reduce code duplication, and it also allows for external code to do something with stats output that's different from printing to stderr. The reason for pushing this now rather than waiting for v12 is that it rethinks some of the API changes made by commit 9fa6f00b1. Seems better for extension authors to endure just one round of API changes not two. Discussion: https://postgr.es/m/CAB=Je-FdtmFZ9y9REHD7VsSrnCkiBhsA4mdsLKSPauwXtQBeNA@mail.gmail.com
2018-03-27 22:46:47 +02:00
MemoryContextSetIdentifier(proc_cxt, prodesc->proname);
Improve memory management for PL/Perl functions. Unlike PL/Tcl, PL/Perl at least made an attempt to clean up after itself when a function gets redefined. But it was still using TopMemoryContext for the fn_mcxt of argument/result I/O functions, resulting in the potential for memory leaks depending on what those functions did, and the retail alloc/free logic was pretty bulky as well. Fix things to use a per-function memory context like the other PLs now do. Tweak a couple of places where things were being done in a not-very-safe order (on the principle that a memory leak is better than leaving global state inconsistent after an error). Also make some minor cosmetic adjustments, mostly in field names, to make the code look similar to the way PL/Tcl does now wherever it's essentially the same logic. Michael Paquier and Tom Lane Discussion: <CAB7nPqSOyAsHC6jL24J1B+oK3p=yyNoFU0Vs_B6fd2kdd5g5WQ@mail.gmail.com>
2016-09-01 01:54:58 +02:00
prodesc->fn_cxt = proc_cxt;
prodesc->fn_refcount = 0;
Change the way we mark tuples as frozen. Instead of changing the tuple xmin to FrozenTransactionId, the combination of HEAP_XMIN_COMMITTED and HEAP_XMIN_INVALID, which were previously never set together, is now defined as HEAP_XMIN_FROZEN. A variety of previous proposals to freeze tuples opportunistically before vacuum_freeze_min_age is reached have foundered on the objection that replacing xmin by FrozenTransactionId might hinder debugging efforts when things in this area go awry; this patch is intended to solve that problem by keeping the XID around (but largely ignoring the value to which it is set). Third-party code that checks for HEAP_XMIN_INVALID on tuples where HEAP_XMIN_COMMITTED might be set will be broken by this change. To fix, use the new accessor macros in htup_details.h rather than consulting the bits directly. HeapTupleHeaderGetXmin has been modified to return FrozenTransactionId when the infomask bits indicate that the tuple is frozen; use HeapTupleHeaderGetRawXmin when you already know that the tuple isn't marked commited or frozen, or want the raw value anyway. We currently do this in routines that display the xmin for user consumption, in tqual.c where it's known to be safe and important for the avoidance of extra cycles, and in the function-caching code for various procedural languages, which shouldn't invalidate the cache just because the tuple gets frozen. Robert Haas and Andres Freund
2013-12-22 21:49:09 +01:00
prodesc->fn_xmin = HeapTupleHeaderGetRawXmin(procTup->t_data);
Combine cmin and cmax fields of HeapTupleHeaders into a single field, by keeping private state in each backend that has inserted and deleted the same tuple during its current top-level transaction. This is sufficient since there is no need to be able to determine the cmin/cmax from any other transaction. This gets us back down to 23-byte headers, removing a penalty paid in 8.0 to support subtransactions. Patch by Heikki Linnakangas, with minor revisions by moi, following a design hashed out awhile back on the pghackers list.
2007-02-09 04:35:35 +01:00
prodesc->fn_tid = procTup->t_self;
Improve memory management for PL/Perl functions. Unlike PL/Tcl, PL/Perl at least made an attempt to clean up after itself when a function gets redefined. But it was still using TopMemoryContext for the fn_mcxt of argument/result I/O functions, resulting in the potential for memory leaks depending on what those functions did, and the retail alloc/free logic was pretty bulky as well. Fix things to use a per-function memory context like the other PLs now do. Tweak a couple of places where things were being done in a not-very-safe order (on the principle that a memory leak is better than leaving global state inconsistent after an error). Also make some minor cosmetic adjustments, mostly in field names, to make the code look similar to the way PL/Tcl does now wherever it's essentially the same logic. Michael Paquier and Tom Lane Discussion: <CAB7nPqSOyAsHC6jL24J1B+oK3p=yyNoFU0Vs_B6fd2kdd5g5WQ@mail.gmail.com>
2016-09-01 01:54:58 +02:00
prodesc->nargs = procStruct->pronargs;
prodesc->arg_out_func = (FmgrInfo *) palloc0(prodesc->nargs * sizeof(FmgrInfo));
prodesc->arg_is_rowtype = (bool *) palloc0(prodesc->nargs * sizeof(bool));
prodesc->arg_arraytype = (Oid *) palloc0(prodesc->nargs * sizeof(Oid));
MemoryContextSwitchTo(oldcontext);
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
Redesign query-snapshot timing so that volatile functions in READ COMMITTED mode see a fresh snapshot for each command in the function, rather than using the latest interactive command's snapshot. Also, suppress fresh snapshots as well as CommandCounterIncrement inside STABLE and IMMUTABLE functions, instead using the snapshot taken for the most closely nested regular query. (This behavior is only sane for read-only functions, so the patch also enforces that such functions contain only SELECT commands.) As per my proposal of 6-Sep-2004; I note that I floated essentially the same proposal on 19-Jun-2002, but that discussion tailed off without any action. Since 8.0 seems like the right place to be taking possibly nontrivial backwards compatibility hits, let's get it done now.
2004-09-13 22:10:13 +02:00
/* Remember if function is STABLE/IMMUTABLE */
prodesc->fn_readonly =
(procStruct->provolatile != PROVOLATILE_VOLATILE);
Improve memory management for PL/Perl functions. Unlike PL/Tcl, PL/Perl at least made an attempt to clean up after itself when a function gets redefined. But it was still using TopMemoryContext for the fn_mcxt of argument/result I/O functions, resulting in the potential for memory leaks depending on what those functions did, and the retail alloc/free logic was pretty bulky as well. Fix things to use a per-function memory context like the other PLs now do. Tweak a couple of places where things were being done in a not-very-safe order (on the principle that a memory leak is better than leaving global state inconsistent after an error). Also make some minor cosmetic adjustments, mostly in field names, to make the code look similar to the way PL/Tcl does now wherever it's essentially the same logic. Michael Paquier and Tom Lane Discussion: <CAB7nPqSOyAsHC6jL24J1B+oK3p=yyNoFU0Vs_B6fd2kdd5g5WQ@mail.gmail.com>
2016-09-01 01:54:58 +02:00
/* Fetch protrftypes */
protrftypes_datum = SysCacheGetAttr(PROCOID, procTup,
Add transforms feature This provides a mechanism for specifying conversions between SQL data types and procedural languages. As examples, there are transforms for hstore and ltree for PL/Perl and PL/Python. reviews by Pavel Stěhule and Andres Freund
2015-04-26 16:33:14 +02:00
Anum_pg_proc_protrftypes, &isnull);
Improve memory management for PL/Perl functions. Unlike PL/Tcl, PL/Perl at least made an attempt to clean up after itself when a function gets redefined. But it was still using TopMemoryContext for the fn_mcxt of argument/result I/O functions, resulting in the potential for memory leaks depending on what those functions did, and the retail alloc/free logic was pretty bulky as well. Fix things to use a per-function memory context like the other PLs now do. Tweak a couple of places where things were being done in a not-very-safe order (on the principle that a memory leak is better than leaving global state inconsistent after an error). Also make some minor cosmetic adjustments, mostly in field names, to make the code look similar to the way PL/Tcl does now wherever it's essentially the same logic. Michael Paquier and Tom Lane Discussion: <CAB7nPqSOyAsHC6jL24J1B+oK3p=yyNoFU0Vs_B6fd2kdd5g5WQ@mail.gmail.com>
2016-09-01 01:54:58 +02:00
MemoryContextSwitchTo(proc_cxt);
prodesc->trftypes = isnull ? NIL : oid_array_to_list(protrftypes_datum);
MemoryContextSwitchTo(oldcontext);
Add transforms feature This provides a mechanism for specifying conversions between SQL data types and procedural languages. As examples, there are transforms for hstore and ltree for PL/Perl and PL/Python. reviews by Pavel Stěhule and Andres Freund
2015-04-26 16:33:14 +02:00
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
/************************************************************
Fix plperl to discard cached function definition after CREATE OR REPLACE FUNCTION. Clean up typlen/typmod errors inherited from pltcl.
2001-10-20 00:43:49 +02:00
* Lookup the pg_language tuple by Oid
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
************************************************************/
Wrap calls to SearchSysCache and related functions using macros. The purpose of this change is to eliminate the need for every caller of SearchSysCache, SearchSysCacheCopy, SearchSysCacheExists, GetSysCacheOid, and SearchSysCacheList to know the maximum number of allowable keys for a syscache entry (currently 4). This will make it far easier to increase the maximum number of keys in a future release should we choose to do so, and it makes the code shorter, too. Design and review by Tom Lane.
2010-02-14 19:42:19 +01:00
langTup = SearchSysCache1(LANGOID,
ObjectIdGetDatum(procStruct->prolang));
Fix plperl to discard cached function definition after CREATE OR REPLACE FUNCTION. Clean up typlen/typmod errors inherited from pltcl.
2001-10-20 00:43:49 +02:00
if (!HeapTupleIsValid(langTup))
Error message editing in src/pl. The plpython module could use another look ... I'm not real certain which errors are strictly internal and which are likely to be provoked by users.
2003-07-26 01:37:31 +02:00
elog(ERROR, "cache lookup failed for language %u",
Fix plperl to discard cached function definition after CREATE OR REPLACE FUNCTION. Clean up typlen/typmod errors inherited from pltcl.
2001-10-20 00:43:49 +02:00
procStruct->prolang);
langStruct = (Form_pg_language) GETSTRUCT(langTup);
Remove WITH OIDS support, change oid catalog column visibility. Previously tables declared WITH OIDS, including a significant fraction of the catalog tables, stored the oid column not as a normal column, but as part of the tuple header. This special column was not shown by default, which was somewhat odd, as it's often (consider e.g. pg_class.oid) one of the more important parts of a row. Neither pg_dump nor COPY included the contents of the oid column by default. The fact that the oid column was not an ordinary column necessitated a significant amount of special case code to support oid columns. That already was painful for the existing, but upcoming work aiming to make table storage pluggable, would have required expanding and duplicating that "specialness" significantly. WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0). Remove it. Removing includes: - CREATE TABLE and ALTER TABLE syntax for declaring the table to be WITH OIDS has been removed (WITH (oids[ = true]) will error out) - pg_dump does not support dumping tables declared WITH OIDS and will issue a warning when dumping one (and ignore the oid column). - restoring an pg_dump archive with pg_restore will warn when restoring a table with oid contents (and ignore the oid column) - COPY will refuse to load binary dump that includes oids. - pg_upgrade will error out when encountering tables declared WITH OIDS, they have to be altered to remove the oid column first. - Functionality to access the oid of the last inserted row (like plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed. The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false) for CREATE TABLE) is still supported. While that requires a bit of support code, it seems unnecessary to break applications / dumps that do not use oids, and are explicit about not using them. The biggest user of WITH OID columns was postgres' catalog. This commit changes all 'magic' oid columns to be columns that are normally declared and stored. To reduce unnecessary query breakage all the newly added columns are still named 'oid', even if a table's column naming scheme would indicate 'reloid' or such. This obviously requires adapting a lot code, mostly replacing oid access via HeapTupleGetOid() with access to the underlying Form_pg_*->oid column. The bootstrap process now assigns oids for all oid columns in genbki.pl that do not have an explicit value (starting at the largest oid previously used), only oids assigned later by oids will be above FirstBootstrapObjectId. As the oid column now is a normal column the special bootstrap syntax for oids has been removed. Oids are not automatically assigned during insertion anymore, all backend code explicitly assigns oids with GetNewOidWithIndex(). For the rare case that insertions into the catalog via SQL are called for the new pg_nextoid() function can be used (which only works on catalog tables). The fact that oid columns on system tables are now normal columns means that they will be included in the set of columns expanded by * (i.e. SELECT * FROM pg_class will now include the table's oid, previously it did not). It'd not technically be hard to hide oid column by default, but that'd mean confusing behavior would either have to be carried forward forever, or it'd cause breakage down the line. While it's not unlikely that further adjustments are needed, the scope/invasiveness of the patch makes it worthwhile to get merge this now. It's painful to maintain externally, too complicated to commit after the code code freeze, and a dependency of a number of other patches. Catversion bump, for obvious reasons. Author: Andres Freund, with contributions by John Naylor Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
2018-11-21 00:36:57 +01:00
prodesc->lang_oid = langStruct->oid;
Fix plperl to discard cached function definition after CREATE OR REPLACE FUNCTION. Clean up typlen/typmod errors inherited from pltcl.
2001-10-20 00:43:49 +02:00
prodesc->lanpltrusted = langStruct->lanpltrusted;
ReleaseSysCache(langTup);
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
/************************************************************
Fix plperl to discard cached function definition after CREATE OR REPLACE FUNCTION. Clean up typlen/typmod errors inherited from pltcl.
2001-10-20 00:43:49 +02:00
* Get the required information for input conversion of the
* return value.
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
************************************************************/
Remove some obsolete procedure-specific code from PLs Since procedures are now declared to return void, code that handled return values for procedures separately is no longer necessary.
2018-03-05 17:51:15 +01:00
if (!is_trigger && !is_event_trigger)
Fix plperl to discard cached function definition after CREATE OR REPLACE FUNCTION. Clean up typlen/typmod errors inherited from pltcl.
2001-10-20 00:43:49 +02:00
{
Support domains over composite types in PL/Perl. In passing, don't insist on rsi->expectedDesc being set unless we actually need it; this allows succeeding in a couple of cases where PL/Perl functions returning setof composite would have failed before, and makes the error message more apropos in other cases. Discussion: https://postgr.es/m/4206.1499798337@sss.pgh.pa.us
2017-10-28 20:02:21 +02:00
Oid rettype = procStruct->prorettype;
typeTup = SearchSysCache1(TYPEOID, ObjectIdGetDatum(rettype));
Fix plperl to discard cached function definition after CREATE OR REPLACE FUNCTION. Clean up typlen/typmod errors inherited from pltcl.
2001-10-20 00:43:49 +02:00
if (!HeapTupleIsValid(typeTup))
Support domains over composite types in PL/Perl. In passing, don't insist on rsi->expectedDesc being set unless we actually need it; this allows succeeding in a couple of cases where PL/Perl functions returning setof composite would have failed before, and makes the error message more apropos in other cases. Discussion: https://postgr.es/m/4206.1499798337@sss.pgh.pa.us
2017-10-28 20:02:21 +02:00
elog(ERROR, "cache lookup failed for type %u", rettype);
Fix plperl to discard cached function definition after CREATE OR REPLACE FUNCTION. Clean up typlen/typmod errors inherited from pltcl.
2001-10-20 00:43:49 +02:00
typeStruct = (Form_pg_type) GETSTRUCT(typeTup);
plperl update from Andrew Dunstan, deriving (I believe) from Command Prompt's plperlNG. Review and minor cleanup/improvements by Joe Conway. Summary of new functionality: - Shared data space and namespace. There is a new global variable %_SHARED that functions can use to store and save data between invocations of a function, or between different functions. Also, all trusted plperl function now share a common Safe container (this is an optimization, also), which they can use for storing non-lexical variables, functions, etc. - Triggers are now supported - Records can now be returned (as a hash reference) - Sets of records can now be returned (as a reference to an array of hash references). - New function spi_exec_query() provided for performing db functions or getting data from db. - Optimization for counting hash keys (Abhijit Menon-Sen) - Allow return of 'record' and 'setof record'
2004-07-01 22:50:22 +02:00
/* Disallow pseudotype result, except VOID or RECORD */
Support enum data types. Along the way, use macros for the values of pg_type.typtype whereever practical. Tom Dunstan, with some kibitzing from Tom Lane.
2007-04-02 05:49:42 +02:00
if (typeStruct->typtype == TYPTYPE_PSEUDO)
Add a bunch of pseudo-types to replace the behavior formerly associated with OPAQUE, as per recent pghackers discussion. I still want to do some more work on the 'cstring' pseudo-type, but I'm going to commit the bulk of the changes now before the tree starts shifting under me ...
2002-08-22 02:01:51 +02:00
{
Support domains over composite types in PL/Perl. In passing, don't insist on rsi->expectedDesc being set unless we actually need it; this allows succeeding in a couple of cases where PL/Perl functions returning setof composite would have failed before, and makes the error message more apropos in other cases. Discussion: https://postgr.es/m/4206.1499798337@sss.pgh.pa.us
2017-10-28 20:02:21 +02:00
if (rettype == VOIDOID ||
rettype == RECORDOID)
Add a bunch of pseudo-types to replace the behavior formerly associated with OPAQUE, as per recent pghackers discussion. I still want to do some more work on the 'cstring' pseudo-type, but I'm going to commit the bulk of the changes now before the tree starts shifting under me ...
2002-08-22 02:01:51 +02:00
/* okay */ ;
Support domains over composite types in PL/Perl. In passing, don't insist on rsi->expectedDesc being set unless we actually need it; this allows succeeding in a couple of cases where PL/Perl functions returning setof composite would have failed before, and makes the error message more apropos in other cases. Discussion: https://postgr.es/m/4206.1499798337@sss.pgh.pa.us
2017-10-28 20:02:21 +02:00
else if (rettype == TRIGGEROID ||
Don't use custom OID symbols in pg_type.dat, either. On the same reasoning as in commit 36b931214, forbid using custom oid_symbol macros in pg_type as well as pg_proc, so that we always rely on the predictable macro names generated by genbki.pl. We do continue to grant grandfather status to the names CASHOID and LSNOID, although those are now considered deprecated aliases for the preferred names MONEYOID and PG_LSNOID. This is because there's likely to be client-side code using the old names, and this bout of neatnik-ism doesn't quite seem worth breaking client code. There might be a case for grandfathering EVTTRIGGEROID, too, since externally-maintained PLs may reference that symbol. But renaming such references to EVENT_TRIGGEROID doesn't seem like a particularly heavy lift --- we make far more significant backend API changes in every major release. For now I didn't add that, but we could reconsider if there's pushback. The other names changed here seem pretty unlikely to have any outside uses. Again, we could add alias macros if there are complaints, but for now I didn't. As before, no need for a catversion bump. John Naylor Discussion: https://postgr.es/m/CAFBsxsHpCbjfoddNGpnnnY5pHwckWfiYkMYSF74PmP1su0+ZOw@mail.gmail.com
2020-10-29 18:33:38 +01:00
rettype == EVENT_TRIGGEROID)
Error message editing in src/pl. The plpython module could use another look ... I'm not real certain which errors are strictly internal and which are likely to be provoked by users.
2003-07-26 01:37:31 +02:00
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
Wording cleanup for error messages. Also change can't -> cannot. Standard English uses "may", "can", and "might" in different ways: may - permission, "You may borrow my rake." can - ability, "I can lift that log." might - possibility, "It might rain today." Unfortunately, in conversational English, their use is often mixed, as in, "You may use this variable to do X", when in fact, "can" is a better choice. Similarly, "It may crash" is better stated, "It might crash".
2007-02-01 20:10:30 +01:00
errmsg("trigger functions can only be called "
At 2005-05-21 20:18:50 +0530, ams@oryx.com wrote: > > > The second issue is where plperl returns a large result set. I have attached the following seven patches to address this problem: 1. Trivial. Replaces some errant spaces with tabs. 2. Trivial. Fixes the spelling of Jan's name, and gets rid of many inane, useless, annoying, and often misleading comments. Here's a sample: "plperl_init_all() - Initialize all". (I have tried to add some useful comments here and there, and will continue to do so now and again.) 3. Trivial. Splits up some long lines. 4. Converts SRFs in PL/Perl to use a Tuplestore and SFRM_Materialize to return the result set, based on the PL/PgSQL model. There are two major consequences: result sets will spill to disk when they can no longer fit in work_mem; and "select foo_srf()" no longer works. (I didn't lose sleep over the latter, since that form is not valid in PL/PgSQL, and it's not documented in PL/Perl.) 5. Trivial, but important. Fixes use of "undef" instead of undef. This would cause empty functions to fail in bizarre ways. I suspect that there's still another (old) bug here. I'll investigate further. 6. Moves the majority of (4) out into a new plperl_return_next() function, to make it possible to expose the functionality to Perl; cleans up some of the code besides. 7. Add an spi_return_next function for use in Perl code. If you want to apply the patches and try them out, 8-composite.diff is what you should use. (Note: my patches depend upon Andrew's use-strict and %_SHARED patches being applied.) Here's something to try: create or replace function foo() returns setof record as $$ $i = 0; for ("World", "PostgreSQL", "PL/Perl") { spi_return_next({f1=>++$i, f2=>'Hello', f3=>$_}); } return; $$ language plperl; select * from foo() as (f1 integer, f2 text, f3 text); (Many thanks to Andrews Dunstan and Supernews for their help.) Abhijit Menon-Sen
2005-06-04 22:33:06 +02:00
"as triggers")));
Add a bunch of pseudo-types to replace the behavior formerly associated with OPAQUE, as per recent pghackers discussion. I still want to do some more work on the 'cstring' pseudo-type, but I'm going to commit the bulk of the changes now before the tree starts shifting under me ...
2002-08-22 02:01:51 +02:00
else
Error message editing in src/pl. The plpython module could use another look ... I'm not real certain which errors are strictly internal and which are likely to be provoked by users.
2003-07-26 01:37:31 +02:00
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
Wordsmithing for PL/Perl messages
2009-02-19 11:33:17 +01:00
errmsg("PL/Perl functions cannot return type %s",
Support domains over composite types in PL/Perl. In passing, don't insist on rsi->expectedDesc being set unless we actually need it; this allows succeeding in a couple of cases where PL/Perl functions returning setof composite would have failed before, and makes the error message more apropos in other cases. Discussion: https://postgr.es/m/4206.1499798337@sss.pgh.pa.us
2017-10-28 20:02:21 +02:00
format_type_be(rettype))));
Add a bunch of pseudo-types to replace the behavior formerly associated with OPAQUE, as per recent pghackers discussion. I still want to do some more work on the 'cstring' pseudo-type, but I'm going to commit the bulk of the changes now before the tree starts shifting under me ...
2002-08-22 02:01:51 +02:00
}
Support domains over composite types in PL/Perl. In passing, don't insist on rsi->expectedDesc being set unless we actually need it; this allows succeeding in a couple of cases where PL/Perl functions returning setof composite would have failed before, and makes the error message more apropos in other cases. Discussion: https://postgr.es/m/4206.1499798337@sss.pgh.pa.us
2017-10-28 20:02:21 +02:00
prodesc->result_oid = rettype;
Try to instill some sanity in plperl's function result processing. Get rid of static variables for SETOF result, don't crash when called from non-FROM context, eliminate dead code, etc.
2004-11-22 21:31:53 +01:00
prodesc->fn_retisset = procStruct->proretset;
Support domains over composite types in PL/Perl. In passing, don't insist on rsi->expectedDesc being set unless we actually need it; this allows succeeding in a couple of cases where PL/Perl functions returning setof composite would have failed before, and makes the error message more apropos in other cases. Discussion: https://postgr.es/m/4206.1499798337@sss.pgh.pa.us
2017-10-28 20:02:21 +02:00
prodesc->fn_retistuple = type_is_rowtype(rettype);
Support subscripting of arbitrary types, not only arrays. This patch generalizes the subscripting infrastructure so that any data type can be subscripted, if it provides a handler function to define what that means. Traditional variable-length (varlena) arrays all use array_subscript_handler(), while the existing fixed-length types that support subscripting use raw_array_subscript_handler(). It's expected that other types that want to use subscripting notation will define their own handlers. (This patch provides no such new features, though; it only lays the foundation for them.) To do this, move the parser's semantic processing of subscripts (including coercion to whatever data type is required) into a method callback supplied by the handler. On the execution side, replace the ExecEvalSubscriptingRef* layer of functions with direct calls to callback-supplied execution routines. (Thus, essentially no new run-time overhead should be caused by this patch. Indeed, there is room to remove some overhead by supplying specialized execution routines. This patch does a little bit in that line, but more could be done.) Additional work is required here and there to remove formerly hard-wired assumptions about the result type, collation, etc of a SubscriptingRef expression node; and to remove assumptions that the subscript values must be integers. One useful side-effect of this is that we now have a less squishy mechanism for identifying whether a data type is a "true" array: instead of wiring in weird rules about typlen, we can look to see if pg_type.typsubscript == F_ARRAY_SUBSCRIPT_HANDLER. For this to be bulletproof, we have to forbid user-defined types from using that handler directly; but there seems no good reason for them to do so. This patch also removes assumptions that the number of subscripts is limited to MAXDIM (6), or indeed has any hard-wired limit. That limit still applies to types handled by array_subscript_handler or raw_array_subscript_handler, but to discourage other dependencies on this constant, I've moved it from c.h to utils/array.h. Dmitry Dolgov, reviewed at various times by Tom Lane, Arthur Zakirov, Peter Eisentraut, Pavel Stehule Discussion: https://postgr.es/m/CA+q6zcVDuGBv=M0FqBYX8DPebS3F_0KQ6OVFobGJPM507_SZ_w@mail.gmail.com Discussion: https://postgr.es/m/CA+q6zcVovR+XY4mfk-7oNk-rF91gH0PebnNfuUjuuDsyHjOcVA@mail.gmail.com
2020-12-09 18:40:37 +01:00
prodesc->fn_retisarray = IsTrueArrayType(typeStruct);
Following up a previous thought I had, yesterday I realised how to return arays nicely without having to make the plperl programmer aware of anything. The attached patch allows plperl to return an arrayref where the function returns an array type. It silently calls a perl function to stringify the array before passing it to the pg array parser. Non-array returns are handled as before (i.e. passed through this process) so it is backwards compatible. I will presently submit regression tests and docs. example: andrew=# create or replace function blah() returns text[][] language plperl as $$ return [['a"b','c,d'],['e\\f','g']]; $$; CREATE FUNCTION andrew=# select blah(); blah ----------------------------- {{"a\"b","c,d"},{"e\\f",g}} This would complete half of the TODO item: . Pass arrays natively instead of as text between plperl and postgres (The other half is translating pg array arguments to perl arrays - that will have to wait for 8.1). Some of this patch is adapted from a previously submitted patch from Sergej Sergeev. Both he and Abhijit Menon-Sen have looked it over briefly and tentatively said it looks ok. Andrew Dunstan
2005-07-10 17:32:47 +02:00
Improve memory management for PL/Perl functions. Unlike PL/Tcl, PL/Perl at least made an attempt to clean up after itself when a function gets redefined. But it was still using TopMemoryContext for the fn_mcxt of argument/result I/O functions, resulting in the potential for memory leaks depending on what those functions did, and the retail alloc/free logic was pretty bulky as well. Fix things to use a per-function memory context like the other PLs now do. Tweak a couple of places where things were being done in a not-very-safe order (on the principle that a memory leak is better than leaving global state inconsistent after an error). Also make some minor cosmetic adjustments, mostly in field names, to make the code look similar to the way PL/Tcl does now wherever it's essentially the same logic. Michael Paquier and Tom Lane Discussion: <CAB7nPqSOyAsHC6jL24J1B+oK3p=yyNoFU0Vs_B6fd2kdd5g5WQ@mail.gmail.com>
2016-09-01 01:54:58 +02:00
fmgr_info_cxt(typeStruct->typinput,
&(prodesc->result_in_func),
proc_cxt);
Infrastructure for I/O of composite types: arrange for the I/O routines of a composite type to get that type's OID as their second parameter, in place of typelem which is useless. The actual changes are mostly centralized in getTypeInputInfo and siblings, but I had to fix a few places that were fetching pg_type.typelem for themselves instead of using the lsyscache.c routines. Also, I renamed all the related variables from 'typelem' to 'typioparam' to discourage people from assuming that they necessarily contain array element types.
2004-06-06 02:41:28 +02:00
prodesc->result_typioparam = getTypeIOParam(typeTup);
Fix plperl to discard cached function definition after CREATE OR REPLACE FUNCTION. Clean up typlen/typmod errors inherited from pltcl.
2001-10-20 00:43:49 +02:00
ReleaseSysCache(typeTup);
}
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
/************************************************************
Fix plperl to discard cached function definition after CREATE OR REPLACE FUNCTION. Clean up typlen/typmod errors inherited from pltcl.
2001-10-20 00:43:49 +02:00
* Get the required information for output conversion
* of all procedure arguments
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
************************************************************/
PL/Perl: Add event trigger support From: Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2013-12-11 14:11:59 +01:00
if (!is_trigger && !is_event_trigger)
Fix plperl to discard cached function definition after CREATE OR REPLACE FUNCTION. Clean up typlen/typmod errors inherited from pltcl.
2001-10-20 00:43:49 +02:00
{
Improve memory management for PL/Perl functions. Unlike PL/Tcl, PL/Perl at least made an attempt to clean up after itself when a function gets redefined. But it was still using TopMemoryContext for the fn_mcxt of argument/result I/O functions, resulting in the potential for memory leaks depending on what those functions did, and the retail alloc/free logic was pretty bulky as well. Fix things to use a per-function memory context like the other PLs now do. Tweak a couple of places where things were being done in a not-very-safe order (on the principle that a memory leak is better than leaving global state inconsistent after an error). Also make some minor cosmetic adjustments, mostly in field names, to make the code look similar to the way PL/Tcl does now wherever it's essentially the same logic. Michael Paquier and Tom Lane Discussion: <CAB7nPqSOyAsHC6jL24J1B+oK3p=yyNoFU0Vs_B6fd2kdd5g5WQ@mail.gmail.com>
2016-09-01 01:54:58 +02:00
int i;
Fix plperl to discard cached function definition after CREATE OR REPLACE FUNCTION. Clean up typlen/typmod errors inherited from pltcl.
2001-10-20 00:43:49 +02:00
for (i = 0; i < prodesc->nargs; i++)
{
Support domains over composite types in PL/Perl. In passing, don't insist on rsi->expectedDesc being set unless we actually need it; this allows succeeding in a couple of cases where PL/Perl functions returning setof composite would have failed before, and makes the error message more apropos in other cases. Discussion: https://postgr.es/m/4206.1499798337@sss.pgh.pa.us
2017-10-28 20:02:21 +02:00
Oid argtype = procStruct->proargtypes.values[i];
typeTup = SearchSysCache1(TYPEOID, ObjectIdGetDatum(argtype));
Fix plperl to discard cached function definition after CREATE OR REPLACE FUNCTION. Clean up typlen/typmod errors inherited from pltcl.
2001-10-20 00:43:49 +02:00
if (!HeapTupleIsValid(typeTup))
Support domains over composite types in PL/Perl. In passing, don't insist on rsi->expectedDesc being set unless we actually need it; this allows succeeding in a couple of cases where PL/Perl functions returning setof composite would have failed before, and makes the error message more apropos in other cases. Discussion: https://postgr.es/m/4206.1499798337@sss.pgh.pa.us
2017-10-28 20:02:21 +02:00
elog(ERROR, "cache lookup failed for type %u", argtype);
Fix plperl to discard cached function definition after CREATE OR REPLACE FUNCTION. Clean up typlen/typmod errors inherited from pltcl.
2001-10-20 00:43:49 +02:00
typeStruct = (Form_pg_type) GETSTRUCT(typeTup);
Support domains over composite types in PL/Perl. In passing, don't insist on rsi->expectedDesc being set unless we actually need it; this allows succeeding in a couple of cases where PL/Perl functions returning setof composite would have failed before, and makes the error message more apropos in other cases. Discussion: https://postgr.es/m/4206.1499798337@sss.pgh.pa.us
2017-10-28 20:02:21 +02:00
/* Disallow pseudotype argument, except RECORD */
Remove useless whitespace at end of lines
2010-11-23 21:27:50 +01:00
if (typeStruct->typtype == TYPTYPE_PSEUDO &&
Support domains over composite types in PL/Perl. In passing, don't insist on rsi->expectedDesc being set unless we actually need it; this allows succeeding in a couple of cases where PL/Perl functions returning setof composite would have failed before, and makes the error message more apropos in other cases. Discussion: https://postgr.es/m/4206.1499798337@sss.pgh.pa.us
2017-10-28 20:02:21 +02:00
argtype != RECORDOID)
Error message editing in src/pl. The plpython module could use another look ... I'm not real certain which errors are strictly internal and which are likely to be provoked by users.
2003-07-26 01:37:31 +02:00
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
Wordsmithing for PL/Perl messages
2009-02-19 11:33:17 +01:00
errmsg("PL/Perl functions cannot accept type %s",
Support domains over composite types in PL/Perl. In passing, don't insist on rsi->expectedDesc being set unless we actually need it; this allows succeeding in a couple of cases where PL/Perl functions returning setof composite would have failed before, and makes the error message more apropos in other cases. Discussion: https://postgr.es/m/4206.1499798337@sss.pgh.pa.us
2017-10-28 20:02:21 +02:00
format_type_be(argtype))));
Add a bunch of pseudo-types to replace the behavior formerly associated with OPAQUE, as per recent pghackers discussion. I still want to do some more work on the 'cstring' pseudo-type, but I'm going to commit the bulk of the changes now before the tree starts shifting under me ...
2002-08-22 02:01:51 +02:00
Support domains over composite types in PL/Perl. In passing, don't insist on rsi->expectedDesc being set unless we actually need it; this allows succeeding in a couple of cases where PL/Perl functions returning setof composite would have failed before, and makes the error message more apropos in other cases. Discussion: https://postgr.es/m/4206.1499798337@sss.pgh.pa.us
2017-10-28 20:02:21 +02:00
if (type_is_rowtype(argtype))
Replace TupleTableSlot convention for whole-row variables and function results with tuples as ordinary varlena Datums. This commit does not in itself do much for us, except eliminate the horrid memory leak associated with evaluation of whole-row variables. However, it lays the groundwork for allowing composite types as table columns, and perhaps some other useful features as well. Per my proposal of a few days ago.
2004-04-01 23:28:47 +02:00
prodesc->arg_is_rowtype[i] = true;
Fix plperl to discard cached function definition after CREATE OR REPLACE FUNCTION. Clean up typlen/typmod errors inherited from pltcl.
2001-10-20 00:43:49 +02:00
else
Replace TupleTableSlot convention for whole-row variables and function results with tuples as ordinary varlena Datums. This commit does not in itself do much for us, except eliminate the horrid memory leak associated with evaluation of whole-row variables. However, it lays the groundwork for allowing composite types as table columns, and perhaps some other useful features as well. Per my proposal of a few days ago.
2004-04-01 23:28:47 +02:00
{
prodesc->arg_is_rowtype[i] = false;
Improve memory management for PL/Perl functions. Unlike PL/Tcl, PL/Perl at least made an attempt to clean up after itself when a function gets redefined. But it was still using TopMemoryContext for the fn_mcxt of argument/result I/O functions, resulting in the potential for memory leaks depending on what those functions did, and the retail alloc/free logic was pretty bulky as well. Fix things to use a per-function memory context like the other PLs now do. Tweak a couple of places where things were being done in a not-very-safe order (on the principle that a memory leak is better than leaving global state inconsistent after an error). Also make some minor cosmetic adjustments, mostly in field names, to make the code look similar to the way PL/Tcl does now wherever it's essentially the same logic. Michael Paquier and Tom Lane Discussion: <CAB7nPqSOyAsHC6jL24J1B+oK3p=yyNoFU0Vs_B6fd2kdd5g5WQ@mail.gmail.com>
2016-09-01 01:54:58 +02:00
fmgr_info_cxt(typeStruct->typoutput,
&(prodesc->arg_out_func[i]),
proc_cxt);
Replace TupleTableSlot convention for whole-row variables and function results with tuples as ordinary varlena Datums. This commit does not in itself do much for us, except eliminate the horrid memory leak associated with evaluation of whole-row variables. However, it lays the groundwork for allowing composite types as table columns, and perhaps some other useful features as well. Per my proposal of a few days ago.
2004-04-01 23:28:47 +02:00
}
Fix plperl to discard cached function definition after CREATE OR REPLACE FUNCTION. Clean up typlen/typmod errors inherited from pltcl.
2001-10-20 00:43:49 +02:00
Support domains over composite types in PL/Perl. In passing, don't insist on rsi->expectedDesc being set unless we actually need it; this allows succeeding in a couple of cases where PL/Perl functions returning setof composite would have failed before, and makes the error message more apropos in other cases. Discussion: https://postgr.es/m/4206.1499798337@sss.pgh.pa.us
2017-10-28 20:02:21 +02:00
/* Identify array-type arguments */
Support subscripting of arbitrary types, not only arrays. This patch generalizes the subscripting infrastructure so that any data type can be subscripted, if it provides a handler function to define what that means. Traditional variable-length (varlena) arrays all use array_subscript_handler(), while the existing fixed-length types that support subscripting use raw_array_subscript_handler(). It's expected that other types that want to use subscripting notation will define their own handlers. (This patch provides no such new features, though; it only lays the foundation for them.) To do this, move the parser's semantic processing of subscripts (including coercion to whatever data type is required) into a method callback supplied by the handler. On the execution side, replace the ExecEvalSubscriptingRef* layer of functions with direct calls to callback-supplied execution routines. (Thus, essentially no new run-time overhead should be caused by this patch. Indeed, there is room to remove some overhead by supplying specialized execution routines. This patch does a little bit in that line, but more could be done.) Additional work is required here and there to remove formerly hard-wired assumptions about the result type, collation, etc of a SubscriptingRef expression node; and to remove assumptions that the subscript values must be integers. One useful side-effect of this is that we now have a less squishy mechanism for identifying whether a data type is a "true" array: instead of wiring in weird rules about typlen, we can look to see if pg_type.typsubscript == F_ARRAY_SUBSCRIPT_HANDLER. For this to be bulletproof, we have to forbid user-defined types from using that handler directly; but there seems no good reason for them to do so. This patch also removes assumptions that the number of subscripts is limited to MAXDIM (6), or indeed has any hard-wired limit. That limit still applies to types handled by array_subscript_handler or raw_array_subscript_handler, but to discourage other dependencies on this constant, I've moved it from c.h to utils/array.h. Dmitry Dolgov, reviewed at various times by Tom Lane, Arthur Zakirov, Peter Eisentraut, Pavel Stehule Discussion: https://postgr.es/m/CA+q6zcVDuGBv=M0FqBYX8DPebS3F_0KQ6OVFobGJPM507_SZ_w@mail.gmail.com Discussion: https://postgr.es/m/CA+q6zcVovR+XY4mfk-7oNk-rF91gH0PebnNfuUjuuDsyHjOcVA@mail.gmail.com
2020-12-09 18:40:37 +01:00
if (IsTrueArrayType(typeStruct))
Support domains over composite types in PL/Perl. In passing, don't insist on rsi->expectedDesc being set unless we actually need it; this allows succeeding in a couple of cases where PL/Perl functions returning setof composite would have failed before, and makes the error message more apropos in other cases. Discussion: https://postgr.es/m/4206.1499798337@sss.pgh.pa.us
2017-10-28 20:02:21 +02:00
prodesc->arg_arraytype[i] = argtype;
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
else
prodesc->arg_arraytype[i] = InvalidOid;
Fix plperl to discard cached function definition after CREATE OR REPLACE FUNCTION. Clean up typlen/typmod errors inherited from pltcl.
2001-10-20 00:43:49 +02:00
ReleaseSysCache(typeTup);
}
}
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
Fix plperl to discard cached function definition after CREATE OR REPLACE FUNCTION. Clean up typlen/typmod errors inherited from pltcl.
2001-10-20 00:43:49 +02:00
/************************************************************
* create the text of the anonymous subroutine.
* we do not use a named subroutine so that we can call directly
* through the reference.
************************************************************/
Add SysCacheGetAttrNotNull for guaranteed not-null attrs When extracting an attr from a cached tuple in the syscache with SysCacheGetAttr the isnull parameter must be checked in case the attr cannot be NULL. For cases when this is known beforehand, a wrapper is introduced which perform the errorhandling internally on behalf of the caller, invoking an elog in case of a NULL attr. Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Peter Eisentraut <peter.eisentraut@enterprisedb.com> Reviewed-by: David Rowley <dgrowleyml@gmail.com> Discussion: https://postgr.es/m/AD76405E-DB45-46B6-941F-17B1EB3A9076@yesql.se
2023-03-25 22:49:33 +01:00
prosrcdatum = SysCacheGetAttrNotNull(PROCOID, procTup,
Anum_pg_proc_prosrc);
Simplify and standardize conversions between TEXT datums and ordinary C strings. This patch introduces four support functions cstring_to_text, cstring_to_text_with_len, text_to_cstring, and text_to_cstring_buffer, and two macros CStringGetTextDatum and TextDatumGetCString. A number of existing macros that provided variants on these themes were removed. Most of the places that need to make such conversions now require just one function or macro call, in place of the multiple notational layers that used to be needed. There are no longer any direct calls of textout or textin, and we got most of the places that were using handmade conversions via memcpy (there may be a few still lurking, though). This commit doesn't make any serious effort to eliminate transient memory leaks caused by detoasting toasted text objects before they reach text_to_cstring. We changed PG_GETARG_TEXT_P to PG_GETARG_TEXT_PP in a few places where it was easy, but much more could be done. Brendan Jurd and Tom Lane
2008-03-25 23:42:46 +01:00
proc_source = TextDatumGetCString(prosrcdatum);
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
/************************************************************
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
* Create the procedure in the appropriate interpreter
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
************************************************************/
Force plperl and plperlu to run in separate interpreters. Create an error on an attempt to create the second interpreter if this is not supported by the perl installation. Per recent -hackers discussion.
2006-11-13 18:13:57 +01:00
Various small improvements and cleanups for PL/Perl. - Allow (ineffective) use of 'require' in plperl If the required module is not already loaded then it dies. So "use strict;" now works in plperl. - Pre-load the feature module if perl >= 5.10. So "use feature :5.10;" now works in plperl. - Stored procedure subs are now given names. The names are not visible in ordinary use, but they make tools like Devel::NYTProf and Devel::Cover much more useful. - Simplified and generalized the subroutine creation code. Now one code path for generating sub source code, not four. Can generate multiple 'use' statements with specific imports (which handles plperl.use_strict currently and can easily be extended to handle a plperl.use_feature=':5.12' in future). - Disallows use of Safe version 2.20 which is broken for PL/Perl. http://rt.perl.org/rt3/Ticket/Display.html?id=72068 - Assorted minor optimizations by pre-growing data structures. Patch from Tim Bunce, reviewed by Alex Hunsaker.
2010-01-27 00:11:56 +01:00
select_perl_context(prodesc->lanpltrusted);
Force plperl and plperlu to run in separate interpreters. Create an error on an attempt to create the second interpreter if this is not supported by the perl installation. Per recent -hackers discussion.
2006-11-13 18:13:57 +01:00
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
prodesc->interp = plperl_active_interp;
Various small improvements and cleanups for PL/Perl. - Allow (ineffective) use of 'require' in plperl If the required module is not already loaded then it dies. So "use strict;" now works in plperl. - Pre-load the feature module if perl >= 5.10. So "use feature :5.10;" now works in plperl. - Stored procedure subs are now given names. The names are not visible in ordinary use, but they make tools like Devel::NYTProf and Devel::Cover much more useful. - Simplified and generalized the subroutine creation code. Now one code path for generating sub source code, not four. Can generate multiple 'use' statements with specific imports (which handles plperl.use_strict currently and can easily be extended to handle a plperl.use_feature=':5.12' in future). - Disallows use of Safe version 2.20 which is broken for PL/Perl. http://rt.perl.org/rt3/Ticket/Display.html?id=72068 - Assorted minor optimizations by pre-growing data structures. Patch from Tim Bunce, reviewed by Alex Hunsaker.
2010-01-27 00:11:56 +01:00
plperl_create_sub(prodesc, proc_source, fn_oid);
Force plperl and plperlu to run in separate interpreters. Create an error on an attempt to create the second interpreter if this is not supported by the perl installation. Per recent -hackers discussion.
2006-11-13 18:13:57 +01:00
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
activate_interpreter(oldinterp);
Force plperl and plperlu to run in separate interpreters. Create an error on an attempt to create the second interpreter if this is not supported by the perl installation. Per recent -hackers discussion.
2006-11-13 18:13:57 +01:00
Fix plperl to discard cached function definition after CREATE OR REPLACE FUNCTION. Clean up typlen/typmod errors inherited from pltcl.
2001-10-20 00:43:49 +02:00
pfree(proc_source);
Improve memory management for PL/Perl functions. Unlike PL/Tcl, PL/Perl at least made an attempt to clean up after itself when a function gets redefined. But it was still using TopMemoryContext for the fn_mcxt of argument/result I/O functions, resulting in the potential for memory leaks depending on what those functions did, and the retail alloc/free logic was pretty bulky as well. Fix things to use a per-function memory context like the other PLs now do. Tweak a couple of places where things were being done in a not-very-safe order (on the principle that a memory leak is better than leaving global state inconsistent after an error). Also make some minor cosmetic adjustments, mostly in field names, to make the code look similar to the way PL/Tcl does now wherever it's essentially the same logic. Michael Paquier and Tom Lane Discussion: <CAB7nPqSOyAsHC6jL24J1B+oK3p=yyNoFU0Vs_B6fd2kdd5g5WQ@mail.gmail.com>
2016-09-01 01:54:58 +02:00
Update plperl to use ereport() not elog() for user-facing messages, so that they will be translatable. Give messages some semblance of conformance to the style guide.
2004-11-29 21:11:06 +01:00
if (!prodesc->reference) /* can this happen? */
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
elog(ERROR, "could not create PL/Perl internal procedure");
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
/************************************************************
Improve memory management for PL/Perl functions. Unlike PL/Tcl, PL/Perl at least made an attempt to clean up after itself when a function gets redefined. But it was still using TopMemoryContext for the fn_mcxt of argument/result I/O functions, resulting in the potential for memory leaks depending on what those functions did, and the retail alloc/free logic was pretty bulky as well. Fix things to use a per-function memory context like the other PLs now do. Tweak a couple of places where things were being done in a not-very-safe order (on the principle that a memory leak is better than leaving global state inconsistent after an error). Also make some minor cosmetic adjustments, mostly in field names, to make the code look similar to the way PL/Tcl does now wherever it's essentially the same logic. Michael Paquier and Tom Lane Discussion: <CAB7nPqSOyAsHC6jL24J1B+oK3p=yyNoFU0Vs_B6fd2kdd5g5WQ@mail.gmail.com>
2016-09-01 01:54:58 +02:00
* OK, link the procedure into the correct hashtable entry.
* Note we assume that the hashtable entry either doesn't exist yet,
* or we already cleared its proc_ptr during the validation attempts
* above. So no need to decrement an old refcount here.
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
************************************************************/
proc_key.user_id = prodesc->lanpltrusted ? GetUserId() : InvalidOid;
proc_ptr = hash_search(plperl_proc_hash, &proc_key,
HASH_ENTER, NULL);
Improve memory management for PL/Perl functions. Unlike PL/Tcl, PL/Perl at least made an attempt to clean up after itself when a function gets redefined. But it was still using TopMemoryContext for the fn_mcxt of argument/result I/O functions, resulting in the potential for memory leaks depending on what those functions did, and the retail alloc/free logic was pretty bulky as well. Fix things to use a per-function memory context like the other PLs now do. Tweak a couple of places where things were being done in a not-very-safe order (on the principle that a memory leak is better than leaving global state inconsistent after an error). Also make some minor cosmetic adjustments, mostly in field names, to make the code look similar to the way PL/Tcl does now wherever it's essentially the same logic. Michael Paquier and Tom Lane Discussion: <CAB7nPqSOyAsHC6jL24J1B+oK3p=yyNoFU0Vs_B6fd2kdd5g5WQ@mail.gmail.com>
2016-09-01 01:54:58 +02:00
/* We assume these two steps can't throw an error: */
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
proc_ptr->proc_ptr = prodesc;
Make plperl safe against functions that are redefined while running. validate_plperl_function() supposed that it could free an old plperl_proc_desc struct immediately upon detecting that it was stale. However, if a plperl function is called recursively, this could result in deleting the struct out from under an outer invocation, leading to misbehavior or crashes. Add a simple reference-count mechanism to ensure that such structs are freed only when the last reference goes away. Per investigation of bug #7516 from Marko Tiikkaja. I am not certain that this error explains his report, because he says he didn't have any recursive calls --- but it's hard to see how else it could have crashed right there. In any case, this definitely fixes some problems in the area. Back-patch to all active branches.
2012-09-10 02:32:54 +02:00
increment_prodesc_refcount(prodesc);
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
}
Improve memory management for PL/Perl functions. Unlike PL/Tcl, PL/Perl at least made an attempt to clean up after itself when a function gets redefined. But it was still using TopMemoryContext for the fn_mcxt of argument/result I/O functions, resulting in the potential for memory leaks depending on what those functions did, and the retail alloc/free logic was pretty bulky as well. Fix things to use a per-function memory context like the other PLs now do. Tweak a couple of places where things were being done in a not-very-safe order (on the principle that a memory leak is better than leaving global state inconsistent after an error). Also make some minor cosmetic adjustments, mostly in field names, to make the code look similar to the way PL/Tcl does now wherever it's essentially the same logic. Michael Paquier and Tom Lane Discussion: <CAB7nPqSOyAsHC6jL24J1B+oK3p=yyNoFU0Vs_B6fd2kdd5g5WQ@mail.gmail.com>
2016-09-01 01:54:58 +02:00
PG_CATCH();
{
/*
* If we got as far as creating a reference, we should be able to use
* free_plperl_function() to clean up. If not, then at most we have
* some PG memory resources in proc_cxt, which we can just delete.
*/
if (prodesc && prodesc->reference)
free_plperl_function(prodesc);
else if (proc_cxt)
MemoryContextDelete(proc_cxt);
/* Be sure to restore the previous interpreter, too, for luck */
activate_interpreter(oldinterp);
PG_RE_THROW();
}
PG_END_TRY();
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
errcontext support in PL/Perl Author: Alexey Klyukin <alexk@commandprompt.com>
2009-09-16 08:06:12 +02:00
/* restore previous error callback */
error_context_stack = plperl_error_context.previous;
Fix plperl to discard cached function definition after CREATE OR REPLACE FUNCTION. Clean up typlen/typmod errors inherited from pltcl.
2001-10-20 00:43:49 +02:00
ReleaseSysCache(procTup);
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
Fix plperl to discard cached function definition after CREATE OR REPLACE FUNCTION. Clean up typlen/typmod errors inherited from pltcl.
2001-10-20 00:43:49 +02:00
return prodesc;
}
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
/* Build a hash from a given composite/row datum */
static SV *
plperl_hash_from_datum(Datum attr)
{
HeapTupleHeader td;
Oid tupType;
int32 tupTypmod;
TupleDesc tupdesc;
HeapTupleData tmptup;
SV *sv;
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
td = DatumGetHeapTupleHeader(attr);
/* Extract rowtype info and find a tupdesc */
tupType = HeapTupleHeaderGetTypeId(td);
tupTypmod = HeapTupleHeaderGetTypMod(td);
tupdesc = lookup_rowtype_tupdesc(tupType, tupTypmod);
/* Build a temporary HeapTuple control structure */
tmptup.t_len = HeapTupleHeaderGetDatumLength(td);
tmptup.t_data = td;
At 2005-05-21 20:18:50 +0530, ams@oryx.com wrote: > > > The second issue is where plperl returns a large result set. I have attached the following seven patches to address this problem: 1. Trivial. Replaces some errant spaces with tabs. 2. Trivial. Fixes the spelling of Jan's name, and gets rid of many inane, useless, annoying, and often misleading comments. Here's a sample: "plperl_init_all() - Initialize all". (I have tried to add some useful comments here and there, and will continue to do so now and again.) 3. Trivial. Splits up some long lines. 4. Converts SRFs in PL/Perl to use a Tuplestore and SFRM_Materialize to return the result set, based on the PL/PgSQL model. There are two major consequences: result sets will spill to disk when they can no longer fit in work_mem; and "select foo_srf()" no longer works. (I didn't lose sleep over the latter, since that form is not valid in PL/PgSQL, and it's not documented in PL/Perl.) 5. Trivial, but important. Fixes use of "undef" instead of undef. This would cause empty functions to fail in bizarre ways. I suspect that there's still another (old) bug here. I'll investigate further. 6. Moves the majority of (4) out into a new plperl_return_next() function, to make it possible to expose the functionality to Perl; cleans up some of the code besides. 7. Add an spi_return_next function for use in Perl code. If you want to apply the patches and try them out, 8-composite.diff is what you should use. (Note: my patches depend upon Andrew's use-strict and %_SHARED patches being applied.) Here's something to try: create or replace function foo() returns setof record as $$ $i = 0; for ("World", "PostgreSQL", "PL/Perl") { spi_return_next({f1=>++$i, f2=>'Hello', f3=>$_}); } return; $$ language plperl; select * from foo() as (f1 integer, f2 text, f3 text); (Many thanks to Andrews Dunstan and Supernews for their help.) Abhijit Menon-Sen
2005-06-04 22:33:06 +02:00
Generated columns This is an SQL-standard feature that allows creating columns that are computed from expressions rather than assigned, similar to a view or materialized view but on a column basis. This implements one kind of generated column: stored (computed on write). Another kind, virtual (computed on read), is planned for the future, and some room is left for it. Reviewed-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Pavel Stehule <pavel.stehule@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/b151f851-4019-bdb1-699e-ebab07d2f40a@2ndquadrant.com
2019-03-30 08:13:09 +01:00
sv = plperl_hash_from_tuple(&tmptup, tupdesc, true);
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
ReleaseTupleDesc(tupdesc);
return sv;
}
/* Build a hash from all attributes of a given tuple. */
Fix multiple causes of breakage in plperl's error handling.
2003-04-20 23:15:34 +02:00
static SV *
Generated columns This is an SQL-standard feature that allows creating columns that are computed from expressions rather than assigned, similar to a view or materialized view but on a column basis. This implements one kind of generated column: stored (computed on write). Another kind, virtual (computed on read), is planned for the future, and some room is left for it. Reviewed-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Pavel Stehule <pavel.stehule@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/b151f851-4019-bdb1-699e-ebab07d2f40a@2ndquadrant.com
2019-03-30 08:13:09 +01:00
plperl_hash_from_tuple(HeapTuple tuple, TupleDesc tupdesc, bool include_generated)
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
{
PL/Perl portability fix: avoid including XSUB.h in plperl.c. In Perl builds that define PERL_IMPLICIT_SYS, XSUB.h defines macros that replace a whole lot of basic libc functions with Perl functions. We can't tolerate that in plperl.c; it breaks at least PG_TRY and probably other stuff. The core idea of this patch is to include XSUB.h only in the .xs files where it's really needed, and to move any code broken by PERL_IMPLICIT_SYS out of the .xs files and into plperl.c. The reason this hasn't been a problem before is that our build techniques did not result in PERL_IMPLICIT_SYS appearing as a #define in PL/Perl, even on some platforms where Perl thinks it is defined. That's about to change in order to fix a nasty portability issue, so we need this work to make the code safe for that. Rather unaccountably, the Perl people chose XSUB.h as the place to provide the versions of the aTHX/aTHX_ macros that are needed by code that's not explicitly aware of the MULTIPLICITY API conventions. Hence, just removing XSUB.h from plperl.c fails miserably. But we can work around that by defining PERL_NO_GET_CONTEXT (which would make the relevant stanza of XSUB.h a no-op anyway). As explained in perlguts.pod, that means we need to add a "dTHX" macro call in every C function that calls a Perl API function. In most of them we just add this at the top; but since the macro fetches the current Perl interpreter pointer, more care is needed in functions that switch the active interpreter. Lack of the macro is easily recognized since it results in bleats about "my_perl" not being defined. (A nice side benefit of this is that it significantly reduces the number of fetches of the current interpreter pointer. On my machine, plperl.so gets more than 10% smaller, and there's probably some performance win too. We could reduce the number of fetches still more by decorating the code with pTHX_/aTHX_ macros to pass the interpreter pointer around, as explained by perlguts.pod; but that's a task for another day.) Formatting note: pgindent seems happy to treat "dTHX;" as a declaration so long as it's the first thing after the left brace, as we'd already observed with respect to the similar macro "dSP;". If you try to put it later in a set of declarations, pgindent puts ugly extra space around it. Having removed XSUB.h from plperl.c, we need only move the support functions for spi_return_next and util_elog (both of which use PG_TRY) out of the .xs files and into plperl.c. This seems sufficient to avoid the known problems caused by PERL_IMPLICIT_SYS, although we could move more code if additional issues emerge. This will need to be back-patched, but first let's see what the buildfarm makes of it. Patch by me, with some help from Ashutosh Sharma Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
2017-07-28 18:25:43 +02:00
dTHX;
I have attached 5 patches (split up for ease of review) to plperl.c. 1. Two minor cleanups: - We don't need to call hv_exists+hv_fetch; we should just check the return value of hv_fetch. - newSVpv("undef",0) is the string "undef", not a real undef. 2. This should fix the bug Andrew Dunstan described in a recent -hackers post. It replaces three bogus "eval_pv(key, 0)" calls with newSVpv, and eliminates another redundant hv_exists+hv_fetch pair. 3. plperl_build_tuple_argument builds up a string of Perl code to create a hash representing the tuple. This patch creates the hash directly. 4. Another minor cleanup: replace a couple of av_store()s with av_push. 5. Analogous to #3 for plperl_trigger_build_args. This patch removes the static sv_add_tuple_value function, which does much the same as two other utility functions defined later, and merges the functionality into plperl_hash_from_tuple. I have tested the patches to the best of my limited ability, but I would appreciate it very much if someone else could review and test them too. (Thanks to Andrew and David Fetter for their help with some testing.) Abhijit Menon-Sen
2004-10-15 19:08:26 +02:00
HV *hv;
Further plperl cleanup: be more paranoid about checking the type of data returned from Perl. Consolidate multiple bits of code to convert a Perl hash to a tuple, and drive the conversion off the keys present in the hash rather than the tuple column names, so we detect error if the hash contains keys it shouldn't. (This means keys not in the hash will silently default to NULL, which seems ok to me.) Fix a bunch of reference-count leaks too.
2004-11-23 01:21:24 +01:00
int i;
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
/* since this function recurses, it could be driven to stack overflow */
check_stack_depth();
I have attached 5 patches (split up for ease of review) to plperl.c. 1. Two minor cleanups: - We don't need to call hv_exists+hv_fetch; we should just check the return value of hv_fetch. - newSVpv("undef",0) is the string "undef", not a real undef. 2. This should fix the bug Andrew Dunstan described in a recent -hackers post. It replaces three bogus "eval_pv(key, 0)" calls with newSVpv, and eliminates another redundant hv_exists+hv_fetch pair. 3. plperl_build_tuple_argument builds up a string of Perl code to create a hash representing the tuple. This patch creates the hash directly. 4. Another minor cleanup: replace a couple of av_store()s with av_push. 5. Analogous to #3 for plperl_trigger_build_args. This patch removes the static sv_add_tuple_value function, which does much the same as two other utility functions defined later, and merges the functionality into plperl_hash_from_tuple. I have tested the patches to the best of my limited ability, but I would appreciate it very much if someone else could review and test them too. (Thanks to Andrew and David Fetter for their help with some testing.) Abhijit Menon-Sen
2004-10-15 19:08:26 +02:00
hv = newHV();
Various small improvements and cleanups for PL/Perl. - Allow (ineffective) use of 'require' in plperl If the required module is not already loaded then it dies. So "use strict;" now works in plperl. - Pre-load the feature module if perl >= 5.10. So "use feature :5.10;" now works in plperl. - Stored procedure subs are now given names. The names are not visible in ordinary use, but they make tools like Devel::NYTProf and Devel::Cover much more useful. - Simplified and generalized the subroutine creation code. Now one code path for generating sub source code, not four. Can generate multiple 'use' statements with specific imports (which handles plperl.use_strict currently and can easily be extended to handle a plperl.use_feature=':5.12' in future). - Disallows use of Safe version 2.20 which is broken for PL/Perl. http://rt.perl.org/rt3/Ticket/Display.html?id=72068 - Assorted minor optimizations by pre-growing data structures. Patch from Tim Bunce, reviewed by Alex Hunsaker.
2010-01-27 00:11:56 +01:00
hv_ksplit(hv, tupdesc->natts); /* pre-grow the hash */
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
for (i = 0; i < tupdesc->natts; i++)
{
Further plperl cleanup: be more paranoid about checking the type of data returned from Perl. Consolidate multiple bits of code to convert a Perl hash to a tuple, and drive the conversion off the keys present in the hash rather than the tuple column names, so we detect error if the hash contains keys it shouldn't. (This means keys not in the hash will silently default to NULL, which seems ok to me.) Fix a bunch of reference-count leaks too.
2004-11-23 01:21:24 +01:00
Datum attr;
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
bool isnull,
typisvarlena;
Further plperl cleanup: be more paranoid about checking the type of data returned from Perl. Consolidate multiple bits of code to convert a Perl hash to a tuple, and drive the conversion off the keys present in the hash rather than the tuple column names, so we detect error if the hash contains keys it shouldn't. (This means keys not in the hash will silently default to NULL, which seems ok to me.) Fix a bunch of reference-count leaks too.
2004-11-23 01:21:24 +01:00
char *attname;
Oid typoutput;
Change tupledesc->attrs[n] to TupleDescAttr(tupledesc, n). This is a mechanical change in preparation for a later commit that will change the layout of TupleDesc. Introducing a macro to abstract the details of where attributes are stored will allow us to change that in separate step and revise it in future. Author: Thomas Munro, editorialized by Andres Freund Reviewed-By: Andres Freund Discussion: https://postgr.es/m/CAEepm=0ZtQ-SpsgCyzzYpsXS6e=kZWqk3g5Ygn3MDV7A8dabUA@mail.gmail.com
2017-08-20 20:19:07 +02:00
Form_pg_attribute att = TupleDescAttr(tupdesc, i);
Further plperl cleanup: be more paranoid about checking the type of data returned from Perl. Consolidate multiple bits of code to convert a Perl hash to a tuple, and drive the conversion off the keys present in the hash rather than the tuple column names, so we detect error if the hash contains keys it shouldn't. (This means keys not in the hash will silently default to NULL, which seems ok to me.) Fix a bunch of reference-count leaks too.
2004-11-23 01:21:24 +01:00
Change tupledesc->attrs[n] to TupleDescAttr(tupledesc, n). This is a mechanical change in preparation for a later commit that will change the layout of TupleDesc. Introducing a macro to abstract the details of where attributes are stored will allow us to change that in separate step and revise it in future. Author: Thomas Munro, editorialized by Andres Freund Reviewed-By: Andres Freund Discussion: https://postgr.es/m/CAEepm=0ZtQ-SpsgCyzzYpsXS6e=kZWqk3g5Ygn3MDV7A8dabUA@mail.gmail.com
2017-08-20 20:19:07 +02:00
if (att->attisdropped)
Looks like plperl has same bug as pltcl.
2003-09-04 17:16:39 +02:00
continue;
Generated columns This is an SQL-standard feature that allows creating columns that are computed from expressions rather than assigned, similar to a view or materialized view but on a column basis. This implements one kind of generated column: stored (computed on write). Another kind, virtual (computed on read), is planned for the future, and some room is left for it. Reviewed-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Pavel Stehule <pavel.stehule@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/b151f851-4019-bdb1-699e-ebab07d2f40a@2ndquadrant.com
2019-03-30 08:13:09 +01:00
if (att->attgenerated)
{
/* don't include unless requested */
if (!include_generated)
continue;
}
Change tupledesc->attrs[n] to TupleDescAttr(tupledesc, n). This is a mechanical change in preparation for a later commit that will change the layout of TupleDesc. Introducing a macro to abstract the details of where attributes are stored will allow us to change that in separate step and revise it in future. Author: Thomas Munro, editorialized by Andres Freund Reviewed-By: Andres Freund Discussion: https://postgr.es/m/CAEepm=0ZtQ-SpsgCyzzYpsXS6e=kZWqk3g5Ygn3MDV7A8dabUA@mail.gmail.com
2017-08-20 20:19:07 +02:00
attname = NameStr(att->attname);
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
attr = heap_getattr(tuple, i + 1, tupdesc, &isnull);
I have attached 5 patches (split up for ease of review) to plperl.c. 1. Two minor cleanups: - We don't need to call hv_exists+hv_fetch; we should just check the return value of hv_fetch. - newSVpv("undef",0) is the string "undef", not a real undef. 2. This should fix the bug Andrew Dunstan described in a recent -hackers post. It replaces three bogus "eval_pv(key, 0)" calls with newSVpv, and eliminates another redundant hv_exists+hv_fetch pair. 3. plperl_build_tuple_argument builds up a string of Perl code to create a hash representing the tuple. This patch creates the hash directly. 4. Another minor cleanup: replace a couple of av_store()s with av_push. 5. Analogous to #3 for plperl_trigger_build_args. This patch removes the static sv_add_tuple_value function, which does much the same as two other utility functions defined later, and merges the functionality into plperl_hash_from_tuple. I have tested the patches to the best of my limited ability, but I would appreciate it very much if someone else could review and test them too. (Thanks to Andrew and David Fetter for their help with some testing.) Abhijit Menon-Sen
2004-10-15 19:08:26 +02:00
if (isnull)
{
Remove usage of &PL_sv_undef in hashes and arrays According to perlguts, &PL_sv_undef is not the right thing to use in those cases because it doesn't behave the same way as an undef value via Perl code. Seems the intuitive way to deal with undef values is subtly enough broken that it's hard to notice when misused. The broken uses got inadvertently introduced in commit 87bb2ade2ce646083f39d5ab3e3307490211ad04 by Alexey Klyukin, Alex Hunsaker and myself on 2011-02-17; no backpatch is necessary. Per testing report from Greg Mullane. Author: Alex Hunsaker
2011-05-30 18:15:13 +02:00
/*
* Store (attname => undef) and move on. Note we can't use
* &PL_sv_undef here; see "AVs, HVs and undefined values" in
* perlguts for an explanation.
*/
hv_store_string(hv, attname, newSV(0));
Fix plperl to discard cached function definition after CREATE OR REPLACE FUNCTION. Clean up typlen/typmod errors inherited from pltcl.
2001-10-20 00:43:49 +02:00
continue;
}
Change tupledesc->attrs[n] to TupleDescAttr(tupledesc, n). This is a mechanical change in preparation for a later commit that will change the layout of TupleDesc. Introducing a macro to abstract the details of where attributes are stored will allow us to change that in separate step and revise it in future. Author: Thomas Munro, editorialized by Andres Freund Reviewed-By: Andres Freund Discussion: https://postgr.es/m/CAEepm=0ZtQ-SpsgCyzzYpsXS6e=kZWqk3g5Ygn3MDV7A8dabUA@mail.gmail.com
2017-08-20 20:19:07 +02:00
if (type_is_rowtype(att->atttypid))
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
{
SV *sv = plperl_hash_from_datum(attr);
hv_store_string(hv, attname, sv);
}
else
{
SV *sv;
Add transforms feature This provides a mechanism for specifying conversions between SQL data types and procedural languages. As examples, there are transforms for hstore and ltree for PL/Perl and PL/Python. reviews by Pavel Stěhule and Andres Freund
2015-04-26 16:33:14 +02:00
Oid funcid;
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
Change tupledesc->attrs[n] to TupleDescAttr(tupledesc, n). This is a mechanical change in preparation for a later commit that will change the layout of TupleDesc. Introducing a macro to abstract the details of where attributes are stored will allow us to change that in separate step and revise it in future. Author: Thomas Munro, editorialized by Andres Freund Reviewed-By: Andres Freund Discussion: https://postgr.es/m/CAEepm=0ZtQ-SpsgCyzzYpsXS6e=kZWqk3g5Ygn3MDV7A8dabUA@mail.gmail.com
2017-08-20 20:19:07 +02:00
if (OidIsValid(get_base_element_type(att->atttypid)))
sv = plperl_ref_from_pg_array(attr, att->atttypid);
else if ((funcid = get_transform_fromsql(att->atttypid, current_call_data->prodesc->lang_oid, current_call_data->prodesc->trftypes)))
Add transforms feature This provides a mechanism for specifying conversions between SQL data types and procedural languages. As examples, there are transforms for hstore and ltree for PL/Perl and PL/Python. reviews by Pavel Stěhule and Andres Freund
2015-04-26 16:33:14 +02:00
sv = (SV *) DatumGetPointer(OidFunctionCall1(funcid, attr));
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
else
{
char *outputstr;
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
/* XXX should have a way to cache these lookups */
Change tupledesc->attrs[n] to TupleDescAttr(tupledesc, n). This is a mechanical change in preparation for a later commit that will change the layout of TupleDesc. Introducing a macro to abstract the details of where attributes are stored will allow us to change that in separate step and revise it in future. Author: Thomas Munro, editorialized by Andres Freund Reviewed-By: Andres Freund Discussion: https://postgr.es/m/CAEepm=0ZtQ-SpsgCyzzYpsXS6e=kZWqk3g5Ygn3MDV7A8dabUA@mail.gmail.com
2017-08-20 20:19:07 +02:00
getTypeOutputInfo(att->atttypid, &typoutput, &typisvarlena);
I have attached 5 patches (split up for ease of review) to plperl.c. 1. Two minor cleanups: - We don't need to call hv_exists+hv_fetch; we should just check the return value of hv_fetch. - newSVpv("undef",0) is the string "undef", not a real undef. 2. This should fix the bug Andrew Dunstan described in a recent -hackers post. It replaces three bogus "eval_pv(key, 0)" calls with newSVpv, and eliminates another redundant hv_exists+hv_fetch pair. 3. plperl_build_tuple_argument builds up a string of Perl code to create a hash representing the tuple. This patch creates the hash directly. 4. Another minor cleanup: replace a couple of av_store()s with av_push. 5. Analogous to #3 for plperl_trigger_build_args. This patch removes the static sv_add_tuple_value function, which does much the same as two other utility functions defined later, and merges the functionality into plperl_hash_from_tuple. I have tested the patches to the best of my limited ability, but I would appreciate it very much if someone else could review and test them too. (Thanks to Andrew and David Fetter for their help with some testing.) Abhijit Menon-Sen
2004-10-15 19:08:26 +02:00
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
outputstr = OidOutputFunctionCall(typoutput, attr);
sv = cstr2sv(outputstr);
pfree(outputstr);
}
Fix memory leak in plperl_hash_from_tuple(), per report from Jean-Max Reymond.
2005-07-03 23:56:16 +02:00
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
hv_store_string(hv, attname, sv);
}
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
}
Further plperl cleanup: be more paranoid about checking the type of data returned from Perl. Consolidate multiple bits of code to convert a Perl hash to a tuple, and drive the conversion off the keys present in the hash rather than the tuple column names, so we detect error if the hash contains keys it shouldn't. (This means keys not in the hash will silently default to NULL, which seems ok to me.) Fix a bunch of reference-count leaks too.
2004-11-23 01:21:24 +01:00
return newRV_noinc((SV *) hv);
Well, I finally solved the linking problem that kept me from making perl secure. Attached is uuencoded tarball to add PL/perl to postgresql. Things I know don't work. -- triggers -- SPI The README file has a _VERY_ short tutorial. Mark Hollomon
2000-01-20 06:08:58 +01:00
}
Redesign query-snapshot timing so that volatile functions in READ COMMITTED mode see a fresh snapshot for each command in the function, rather than using the latest interactive command's snapshot. Also, suppress fresh snapshots as well as CommandCounterIncrement inside STABLE and IMMUTABLE functions, instead using the snapshot taken for the most closely nested regular query. (This behavior is only sane for read-only functions, so the patch also enforces that such functions contain only SELECT commands.) As per my proposal of 6-Sep-2004; I note that I floated essentially the same proposal on 19-Jun-2002, but that discussion tailed off without any action. Since 8.0 seems like the right place to be taking possibly nontrivial backwards compatibility hits, let's get it done now.
2004-09-13 22:10:13 +02:00
Add plperl.on_perl_init setting to provide for initializing the perl library on load. Also, handle END blocks in plperl. Database access is disallowed during both these operations, although it might be allowed in END blocks in future. Patch from Tim Bunce.
2010-01-30 02:46:57 +01:00
static void
Don't use function definitions looking like old-style ones. This fixes a bunch of somewhat pedantic warnings with new compilers. Since by far the majority of other functions definitions use the (void) style it just seems to be consistent to do so as well in the remaining few places.
2015-08-15 17:25:00 +02:00
check_spi_usage_allowed(void)
Add plperl.on_perl_init setting to provide for initializing the perl library on load. Also, handle END blocks in plperl. Database access is disallowed during both these operations, although it might be allowed in END blocks in future. Patch from Tim Bunce.
2010-01-30 02:46:57 +01:00
{
Add plperl.on_plperl_init and plperl.on_plperlu_init settings for language-specific startup. Rename recently added plperl.on_perl_init to plperl.on_init. Also, code cleanup for utf8 hack. Patch from Tim Bunce, reviewed by Alex Hunsaker.
2010-02-12 20:35:25 +01:00
/* see comment in plperl_fini() */
Add plperl.on_perl_init setting to provide for initializing the perl library on load. Also, handle END blocks in plperl. Database access is disallowed during both these operations, although it might be allowed in END blocks in future. Patch from Tim Bunce.
2010-01-30 02:46:57 +01:00
if (plperl_ending)
{
/* simple croak as we don't want to involve PostgreSQL code */
croak("SPI functions can not be used in END blocks");
}
Disallow execution of SPI functions during plperl function compilation. Perl can be convinced to execute user-defined code during compilation of a plperl function (or at least a plperlu function). That's not such a big problem as long as the activity is confined within the Perl interpreter, and it's not clear we could do anything about that anyway. However, if such code tries to use plperl's SPI functions, we have a bigger problem. In the first place, those functions are likely to crash because current_call_data->prodesc isn't set up yet. In the second place, because it isn't set up, we lack critical info such as whether the function is supposed to be read-only. And in the third place, this path allows code execution during function validation, which is strongly discouraged because of the potential for security exploits. Hence, reject execution of the SPI functions until compilation is finished. While here, add check_spi_usage_allowed() calls to various functions that hadn't gotten the memo about checking that. I think that perhaps plperl_sv_to_literal may have been intentionally omitted on the grounds that it was safe at the time; but if so, the addition of transforms functionality changed that. The others are more recently added and seem to be flat-out oversights. Per report from Mark Murawski. Back-patch to all supported branches. Discussion: https://postgr.es/m/9acdf918-7fff-4f40-f750-2ffa84f083d2@intellasoft.net
2022-02-25 23:40:21 +01:00
/*
* Disallow SPI usage if we're not executing a fully-compiled plperl
* function. It might seem impossible to get here in that case, but there
* are cases where Perl will try to execute code during compilation. If
* we proceed we are likely to crash trying to dereference the prodesc
* pointer. Working around that might be possible, but it seems unwise
* because it'd allow code execution to happen while validating a
* function, which is undesirable.
*/
if (current_call_data == NULL || current_call_data->prodesc == NULL)
{
/* simple croak as we don't want to involve PostgreSQL code */
croak("SPI functions can not be used during function compilation");
}
Add plperl.on_perl_init setting to provide for initializing the perl library on load. Also, handle END blocks in plperl. Database access is disallowed during both these operations, although it might be allowed in END blocks in future. Patch from Tim Bunce.
2010-01-30 02:46:57 +01:00
}
Redesign query-snapshot timing so that volatile functions in READ COMMITTED mode see a fresh snapshot for each command in the function, rather than using the latest interactive command's snapshot. Also, suppress fresh snapshots as well as CommandCounterIncrement inside STABLE and IMMUTABLE functions, instead using the snapshot taken for the most closely nested regular query. (This behavior is only sane for read-only functions, so the patch also enforces that such functions contain only SELECT commands.) As per my proposal of 6-Sep-2004; I note that I floated essentially the same proposal on 19-Jun-2002, but that discussion tailed off without any action. Since 8.0 seems like the right place to be taking possibly nontrivial backwards compatibility hits, let's get it done now.
2004-09-13 22:10:13 +02:00
HV *
plperl_spi_exec(char *query, int limit)
{
HV *ret_hv;
Fix plperl and pltcl error handling per my previous proposal. SPI operations are now run as subtransactions, so that errors in them can be reported as ordinary Perl or Tcl errors and caught by the normal error handling convention of those languages. Also do some minor code cleanup in pltcl.c: extract a large chunk of duplicated code in pltcl_SPI_execute and pltcl_SPI_execute_plan into a shared subroutine.
2004-11-21 22:17:07 +01:00
/*
* Execute the query inside a sub-transaction, so we can cope with errors
* sanely
*/
MemoryContext oldcontext = CurrentMemoryContext;
ResourceOwner oldowner = CurrentResourceOwner;
Add plperl.on_perl_init setting to provide for initializing the perl library on load. Also, handle END blocks in plperl. Database access is disallowed during both these operations, although it might be allowed in END blocks in future. Patch from Tim Bunce.
2010-01-30 02:46:57 +01:00
check_spi_usage_allowed();
Fix plperl and pltcl error handling per my previous proposal. SPI operations are now run as subtransactions, so that errors in them can be reported as ordinary Perl or Tcl errors and caught by the normal error handling convention of those languages. Also do some minor code cleanup in pltcl.c: extract a large chunk of duplicated code in pltcl_SPI_execute and pltcl_SPI_execute_plan into a shared subroutine.
2004-11-21 22:17:07 +01:00
BeginInternalSubTransaction(NULL);
/* Want to run inside function's memory context */
MemoryContextSwitchTo(oldcontext);
PG_TRY();
{
int spi_rv;
Add checks for valid encoding of query strings passed to SPI by plperl.
2010-03-09 03:48:33 +01:00
pg_verifymbstr(query, strlen(query), false);
Per a bug report from Theo Schlossnagle, plperl_return_next() leaks memory in the executor's per-query memory context. It also inefficient: it invokes get_call_result_type() and TupleDescGetAttInMetadata() for every call to return_next, rather than invoking them once (per PL/Perl function call) and memoizing the result. This patch makes the following changes: - refactor the code to include all the "per PL/Perl function call" data inside a single struct, "current_call_data". This means we don't need to save and restore N pointers for every recursive call into PL/Perl, we can just save and restore one. - lookup the return type metadata needed by plperl_return_next() once, and then stash it in "current_call_data", so as to avoid doing the lookup for every call to return_next. - create a temporary memory context in which to evaluate the return type's input functions. This memory context is reset for each call to return_next. The patch appears to fix the memory leak, and substantially reduces the overhead imposed by return_next.
2006-01-28 04:28:15 +01:00
spi_rv = SPI_execute(query, current_call_data->prodesc->fn_readonly,
Fix plperl and pltcl error handling per my previous proposal. SPI operations are now run as subtransactions, so that errors in them can be reported as ordinary Perl or Tcl errors and caught by the normal error handling convention of those languages. Also do some minor code cleanup in pltcl.c: extract a large chunk of duplicated code in pltcl_SPI_execute and pltcl_SPI_execute_plan into a shared subroutine.
2004-11-21 22:17:07 +01:00
limit);
ret_hv = plperl_spi_execute_fetch_result(SPI_tuptable, SPI_processed,
spi_rv);
/* Commit the inner transaction, return to outer xact context */
ReleaseCurrentSubTransaction();
MemoryContextSwitchTo(oldcontext);
CurrentResourceOwner = oldowner;
}
PG_CATCH();
{
ErrorData *edata;
/* Save error info */
MemoryContextSwitchTo(oldcontext);
edata = CopyErrorData();
FlushErrorState();
/* Abort the inner transaction */
RollbackAndReleaseCurrentSubTransaction();
MemoryContextSwitchTo(oldcontext);
CurrentResourceOwner = oldowner;
/* Punt the error to Perl */
Fix plperl to handle non-ASCII error message texts correctly. We were passing error message texts to croak() verbatim, which turns out not to work if the text contains non-ASCII characters; Perl mangles their encoding, as reported in bug #13638 from Michal Leinweber. To fix, convert the text into a UTF8-encoded SV first. It's hard to test this without risking failures in different database encodings; but we can follow the lead of plpython, which is already assuming that no-break space (U+00A0) has an equivalent in all encodings we care about running the regression tests in (cf commit 2dfa15de5). Back-patch to 9.1. The code is quite different in 9.0, and anyway it seems too risky to put something like this into 9.0's final minor release. Alex Hunsaker, with suggestions from Tim Bunce and Tom Lane
2015-09-29 16:52:22 +02:00
croak_cstr(edata->message);
Fix plperl and pltcl error handling per my previous proposal. SPI operations are now run as subtransactions, so that errors in them can be reported as ordinary Perl or Tcl errors and caught by the normal error handling convention of those languages. Also do some minor code cleanup in pltcl.c: extract a large chunk of duplicated code in pltcl_SPI_execute and pltcl_SPI_execute_plan into a shared subroutine.
2004-11-21 22:17:07 +01:00
/* Can't get here, but keep compiler quiet */
return NULL;
}
PG_END_TRY();
Redesign query-snapshot timing so that volatile functions in READ COMMITTED mode see a fresh snapshot for each command in the function, rather than using the latest interactive command's snapshot. Also, suppress fresh snapshots as well as CommandCounterIncrement inside STABLE and IMMUTABLE functions, instead using the snapshot taken for the most closely nested regular query. (This behavior is only sane for read-only functions, so the patch also enforces that such functions contain only SELECT commands.) As per my proposal of 6-Sep-2004; I note that I floated essentially the same proposal on 19-Jun-2002, but that discussion tailed off without any action. Since 8.0 seems like the right place to be taking possibly nontrivial backwards compatibility hits, let's get it done now.
2004-09-13 22:10:13 +02:00
return ret_hv;
}
At 2005-05-21 20:18:50 +0530, ams@oryx.com wrote: > > > The second issue is where plperl returns a large result set. I have attached the following seven patches to address this problem: 1. Trivial. Replaces some errant spaces with tabs. 2. Trivial. Fixes the spelling of Jan's name, and gets rid of many inane, useless, annoying, and often misleading comments. Here's a sample: "plperl_init_all() - Initialize all". (I have tried to add some useful comments here and there, and will continue to do so now and again.) 3. Trivial. Splits up some long lines. 4. Converts SRFs in PL/Perl to use a Tuplestore and SFRM_Materialize to return the result set, based on the PL/PgSQL model. There are two major consequences: result sets will spill to disk when they can no longer fit in work_mem; and "select foo_srf()" no longer works. (I didn't lose sleep over the latter, since that form is not valid in PL/PgSQL, and it's not documented in PL/Perl.) 5. Trivial, but important. Fixes use of "undef" instead of undef. This would cause empty functions to fail in bizarre ways. I suspect that there's still another (old) bug here. I'll investigate further. 6. Moves the majority of (4) out into a new plperl_return_next() function, to make it possible to expose the functionality to Perl; cleans up some of the code besides. 7. Add an spi_return_next function for use in Perl code. If you want to apply the patches and try them out, 8-composite.diff is what you should use. (Note: my patches depend upon Andrew's use-strict and %_SHARED patches being applied.) Here's something to try: create or replace function foo() returns setof record as $$ $i = 0; for ("World", "PostgreSQL", "PL/Perl") { spi_return_next({f1=>++$i, f2=>'Hello', f3=>$_}); } return; $$ language plperl; select * from foo() as (f1 integer, f2 text, f3 text); (Many thanks to Andrews Dunstan and Supernews for their help.) Abhijit Menon-Sen
2005-06-04 22:33:06 +02:00
Redesign query-snapshot timing so that volatile functions in READ COMMITTED mode see a fresh snapshot for each command in the function, rather than using the latest interactive command's snapshot. Also, suppress fresh snapshots as well as CommandCounterIncrement inside STABLE and IMMUTABLE functions, instead using the snapshot taken for the most closely nested regular query. (This behavior is only sane for read-only functions, so the patch also enforces that such functions contain only SELECT commands.) As per my proposal of 6-Sep-2004; I note that I floated essentially the same proposal on 19-Jun-2002, but that discussion tailed off without any action. Since 8.0 seems like the right place to be taking possibly nontrivial backwards compatibility hits, let's get it done now.
2004-09-13 22:10:13 +02:00
static HV *
Widen query numbers-of-tuples-processed counters to uint64. This patch widens SPI_processed, EState's es_processed field, PortalData's portalPos field, FuncCallContext's call_cntr and max_calls fields, ExecutorRun's count argument, PortalRunFetch's result, and the max number of rows in a SPITupleTable to uint64, and deals with (I hope) all the ensuing fallout. Some of these values were declared uint32 before, and others "long". I also removed PortalData's posOverflow field, since that logic seems pretty useless given that portalPos is now always 64 bits. The user-visible results are that command tags for SELECT etc will correctly report tuple counts larger than 4G, as will plpgsql's GET GET DIAGNOSTICS ... ROW_COUNT command. Queries processing more tuples than that are still not exactly the norm, but they're becoming more common. Most values associated with FETCH/MOVE distances, such as PortalRun's count argument and the count argument of most SPI functions that have one, remain declared as "long". It's not clear whether it would be worth promoting those to int64; but it would definitely be a large dollop of additional API churn on top of this, and it would only help 32-bit platforms which seem relatively less likely to see any benefit. Andreas Scherbaum, reviewed by Christian Ullrich, additional hacking by me
2016-03-12 22:05:10 +01:00
plperl_spi_execute_fetch_result(SPITupleTable *tuptable, uint64 processed,
Fix plperl and pltcl error handling per my previous proposal. SPI operations are now run as subtransactions, so that errors in them can be reported as ordinary Perl or Tcl errors and caught by the normal error handling convention of those languages. Also do some minor code cleanup in pltcl.c: extract a large chunk of duplicated code in pltcl_SPI_execute and pltcl_SPI_execute_plan into a shared subroutine.
2004-11-21 22:17:07 +01:00
int status)
Redesign query-snapshot timing so that volatile functions in READ COMMITTED mode see a fresh snapshot for each command in the function, rather than using the latest interactive command's snapshot. Also, suppress fresh snapshots as well as CommandCounterIncrement inside STABLE and IMMUTABLE functions, instead using the snapshot taken for the most closely nested regular query. (This behavior is only sane for read-only functions, so the patch also enforces that such functions contain only SELECT commands.) As per my proposal of 6-Sep-2004; I note that I floated essentially the same proposal on 19-Jun-2002, but that discussion tailed off without any action. Since 8.0 seems like the right place to be taking possibly nontrivial backwards compatibility hits, let's get it done now.
2004-09-13 22:10:13 +02:00
{
PL/Perl portability fix: avoid including XSUB.h in plperl.c. In Perl builds that define PERL_IMPLICIT_SYS, XSUB.h defines macros that replace a whole lot of basic libc functions with Perl functions. We can't tolerate that in plperl.c; it breaks at least PG_TRY and probably other stuff. The core idea of this patch is to include XSUB.h only in the .xs files where it's really needed, and to move any code broken by PERL_IMPLICIT_SYS out of the .xs files and into plperl.c. The reason this hasn't been a problem before is that our build techniques did not result in PERL_IMPLICIT_SYS appearing as a #define in PL/Perl, even on some platforms where Perl thinks it is defined. That's about to change in order to fix a nasty portability issue, so we need this work to make the code safe for that. Rather unaccountably, the Perl people chose XSUB.h as the place to provide the versions of the aTHX/aTHX_ macros that are needed by code that's not explicitly aware of the MULTIPLICITY API conventions. Hence, just removing XSUB.h from plperl.c fails miserably. But we can work around that by defining PERL_NO_GET_CONTEXT (which would make the relevant stanza of XSUB.h a no-op anyway). As explained in perlguts.pod, that means we need to add a "dTHX" macro call in every C function that calls a Perl API function. In most of them we just add this at the top; but since the macro fetches the current Perl interpreter pointer, more care is needed in functions that switch the active interpreter. Lack of the macro is easily recognized since it results in bleats about "my_perl" not being defined. (A nice side benefit of this is that it significantly reduces the number of fetches of the current interpreter pointer. On my machine, plperl.so gets more than 10% smaller, and there's probably some performance win too. We could reduce the number of fetches still more by decorating the code with pTHX_/aTHX_ macros to pass the interpreter pointer around, as explained by perlguts.pod; but that's a task for another day.) Formatting note: pgindent seems happy to treat "dTHX;" as a declaration so long as it's the first thing after the left brace, as we'd already observed with respect to the similar macro "dSP;". If you try to put it later in a set of declarations, pgindent puts ugly extra space around it. Having removed XSUB.h from plperl.c, we need only move the support functions for spi_return_next and util_elog (both of which use PG_TRY) out of the .xs files and into plperl.c. This seems sufficient to avoid the known problems caused by PERL_IMPLICIT_SYS, although we could move more code if additional issues emerge. This will need to be back-patched, but first let's see what the buildfarm makes of it. Patch by me, with some help from Ashutosh Sharma Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
2017-07-28 18:25:43 +02:00
dTHX;
Redesign query-snapshot timing so that volatile functions in READ COMMITTED mode see a fresh snapshot for each command in the function, rather than using the latest interactive command's snapshot. Also, suppress fresh snapshots as well as CommandCounterIncrement inside STABLE and IMMUTABLE functions, instead using the snapshot taken for the most closely nested regular query. (This behavior is only sane for read-only functions, so the patch also enforces that such functions contain only SELECT commands.) As per my proposal of 6-Sep-2004; I note that I floated essentially the same proposal on 19-Jun-2002, but that discussion tailed off without any action. Since 8.0 seems like the right place to be taking possibly nontrivial backwards compatibility hits, let's get it done now.
2004-09-13 22:10:13 +02:00
HV *result;
Add plperl.on_perl_init setting to provide for initializing the perl library on load. Also, handle END blocks in plperl. Database access is disallowed during both these operations, although it might be allowed in END blocks in future. Patch from Tim Bunce.
2010-01-30 02:46:57 +01:00
check_spi_usage_allowed();
Redesign query-snapshot timing so that volatile functions in READ COMMITTED mode see a fresh snapshot for each command in the function, rather than using the latest interactive command's snapshot. Also, suppress fresh snapshots as well as CommandCounterIncrement inside STABLE and IMMUTABLE functions, instead using the snapshot taken for the most closely nested regular query. (This behavior is only sane for read-only functions, so the patch also enforces that such functions contain only SELECT commands.) As per my proposal of 6-Sep-2004; I note that I floated essentially the same proposal on 19-Jun-2002, but that discussion tailed off without any action. Since 8.0 seems like the right place to be taking possibly nontrivial backwards compatibility hits, let's get it done now.
2004-09-13 22:10:13 +02:00
result = newHV();
Adjust plperl to ensure that all strings and hash keys passed to Perl are marked as UTF8 when the database encoding is UTF8. This should avoid inconsistencies like that exhibited in bug #2683 from Vitali Stupin.
2006-10-15 20:56:39 +02:00
hv_store_string(result, "status",
Force strings passed to and from plperl to be in UTF8 encoding. String are converted to UTF8 on the way into perl and to the database encoding on the way back. This avoids a number of observed anomalies, and ensures Perl a consistent view of the world. Some minor code cleanups are also accomplished. Alex Hunsaker, reviewed by Andy Colson.
2011-02-06 23:29:26 +01:00
cstr2sv(SPI_result_code_string(status)));
Adjust plperl to ensure that all strings and hash keys passed to Perl are marked as UTF8 when the database encoding is UTF8. This should avoid inconsistencies like that exhibited in bug #2683 from Vitali Stupin.
2006-10-15 20:56:39 +02:00
hv_store_string(result, "processed",
Improve conversions from uint64 to Perl types. Perl's integers are pointer-sized, so can hold more than INT_MAX on LP64 platforms, and come in both signed (IV) and unsigned (UV). Floating point values (NV) may also be larger than double. Since Perl 5.19.4 array indices are SSize_t instead of I32, so allow up to SSize_t_max on those versions. The limit is not imposed just by av_extend's argument type, but all the array handling code, so remove the speculative comment. Dagfinn Ilmari Mannsåker
2016-03-14 19:38:36 +01:00
(processed > (uint64) UV_MAX) ?
newSVnv((NV) processed) :
newSVuv((UV) processed));
Redesign query-snapshot timing so that volatile functions in READ COMMITTED mode see a fresh snapshot for each command in the function, rather than using the latest interactive command's snapshot. Also, suppress fresh snapshots as well as CommandCounterIncrement inside STABLE and IMMUTABLE functions, instead using the snapshot taken for the most closely nested regular query. (This behavior is only sane for read-only functions, so the patch also enforces that such functions contain only SELECT commands.) As per my proposal of 6-Sep-2004; I note that I floated essentially the same proposal on 19-Jun-2002, but that discussion tailed off without any action. Since 8.0 seems like the right place to be taking possibly nontrivial backwards compatibility hits, let's get it done now.
2004-09-13 22:10:13 +02:00
Add new return codes SPI_OK_INSERT_RETURNING etc to the SPI API. Fix all the standard PLs to be able to return tuples from FOO_RETURNING statements as well as utility statements that return tuples. Also, fix oversight that SPI_processed wasn't set for a utility statement returning tuples. Per recent discussion.
2006-08-28 01:47:58 +02:00
if (status > 0 && tuptable)
Redesign query-snapshot timing so that volatile functions in READ COMMITTED mode see a fresh snapshot for each command in the function, rather than using the latest interactive command's snapshot. Also, suppress fresh snapshots as well as CommandCounterIncrement inside STABLE and IMMUTABLE functions, instead using the snapshot taken for the most closely nested regular query. (This behavior is only sane for read-only functions, so the patch also enforces that such functions contain only SELECT commands.) As per my proposal of 6-Sep-2004; I note that I floated essentially the same proposal on 19-Jun-2002, but that discussion tailed off without any action. Since 8.0 seems like the right place to be taking possibly nontrivial backwards compatibility hits, let's get it done now.
2004-09-13 22:10:13 +02:00
{
Fix plperl and pltcl error handling per my previous proposal. SPI operations are now run as subtransactions, so that errors in them can be reported as ordinary Perl or Tcl errors and caught by the normal error handling convention of those languages. Also do some minor code cleanup in pltcl.c: extract a large chunk of duplicated code in pltcl_SPI_execute and pltcl_SPI_execute_plan into a shared subroutine.
2004-11-21 22:17:07 +01:00
AV *rows;
Further plperl cleanup: be more paranoid about checking the type of data returned from Perl. Consolidate multiple bits of code to convert a Perl hash to a tuple, and drive the conversion off the keys present in the hash rather than the tuple column names, so we detect error if the hash contains keys it shouldn't. (This means keys not in the hash will silently default to NULL, which seems ok to me.) Fix a bunch of reference-count leaks too.
2004-11-23 01:21:24 +01:00
SV *row;
Widen query numbers-of-tuples-processed counters to uint64. This patch widens SPI_processed, EState's es_processed field, PortalData's portalPos field, FuncCallContext's call_cntr and max_calls fields, ExecutorRun's count argument, PortalRunFetch's result, and the max number of rows in a SPITupleTable to uint64, and deals with (I hope) all the ensuing fallout. Some of these values were declared uint32 before, and others "long". I also removed PortalData's posOverflow field, since that logic seems pretty useless given that portalPos is now always 64 bits. The user-visible results are that command tags for SELECT etc will correctly report tuple counts larger than 4G, as will plpgsql's GET GET DIAGNOSTICS ... ROW_COUNT command. Queries processing more tuples than that are still not exactly the norm, but they're becoming more common. Most values associated with FETCH/MOVE distances, such as PortalRun's count argument and the count argument of most SPI functions that have one, remain declared as "long". It's not clear whether it would be worth promoting those to int64; but it would definitely be a large dollop of additional API churn on top of this, and it would only help 32-bit platforms which seem relatively less likely to see any benefit. Andreas Scherbaum, reviewed by Christian Ullrich, additional hacking by me
2016-03-12 22:05:10 +01:00
uint64 i;
Improve conversions from uint64 to Perl types. Perl's integers are pointer-sized, so can hold more than INT_MAX on LP64 platforms, and come in both signed (IV) and unsigned (UV). Floating point values (NV) may also be larger than double. Since Perl 5.19.4 array indices are SSize_t instead of I32, so allow up to SSize_t_max on those versions. The limit is not imposed just by av_extend's argument type, but all the array handling code, so remove the speculative comment. Dagfinn Ilmari Mannsåker
2016-03-14 19:38:36 +01:00
/* Prevent overflow in call to av_extend() */
if (processed > (uint64) AV_SIZE_MAX)
Widen query numbers-of-tuples-processed counters to uint64. This patch widens SPI_processed, EState's es_processed field, PortalData's portalPos field, FuncCallContext's call_cntr and max_calls fields, ExecutorRun's count argument, PortalRunFetch's result, and the max number of rows in a SPITupleTable to uint64, and deals with (I hope) all the ensuing fallout. Some of these values were declared uint32 before, and others "long". I also removed PortalData's posOverflow field, since that logic seems pretty useless given that portalPos is now always 64 bits. The user-visible results are that command tags for SELECT etc will correctly report tuple counts larger than 4G, as will plpgsql's GET GET DIAGNOSTICS ... ROW_COUNT command. Queries processing more tuples than that are still not exactly the norm, but they're becoming more common. Most values associated with FETCH/MOVE distances, such as PortalRun's count argument and the count argument of most SPI functions that have one, remain declared as "long". It's not clear whether it would be worth promoting those to int64; but it would definitely be a large dollop of additional API churn on top of this, and it would only help 32-bit platforms which seem relatively less likely to see any benefit. Andreas Scherbaum, reviewed by Christian Ullrich, additional hacking by me
2016-03-12 22:05:10 +01:00
ereport(ERROR,
(errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED),
errmsg("query result has too many rows to fit in a Perl array")));
Redesign query-snapshot timing so that volatile functions in READ COMMITTED mode see a fresh snapshot for each command in the function, rather than using the latest interactive command's snapshot. Also, suppress fresh snapshots as well as CommandCounterIncrement inside STABLE and IMMUTABLE functions, instead using the snapshot taken for the most closely nested regular query. (This behavior is only sane for read-only functions, so the patch also enforces that such functions contain only SELECT commands.) As per my proposal of 6-Sep-2004; I note that I floated essentially the same proposal on 19-Jun-2002, but that discussion tailed off without any action. Since 8.0 seems like the right place to be taking possibly nontrivial backwards compatibility hits, let's get it done now.
2004-09-13 22:10:13 +02:00
Fix plperl and pltcl error handling per my previous proposal. SPI operations are now run as subtransactions, so that errors in them can be reported as ordinary Perl or Tcl errors and caught by the normal error handling convention of those languages. Also do some minor code cleanup in pltcl.c: extract a large chunk of duplicated code in pltcl_SPI_execute and pltcl_SPI_execute_plan into a shared subroutine.
2004-11-21 22:17:07 +01:00
rows = newAV();
Various small improvements and cleanups for PL/Perl. - Allow (ineffective) use of 'require' in plperl If the required module is not already loaded then it dies. So "use strict;" now works in plperl. - Pre-load the feature module if perl >= 5.10. So "use feature :5.10;" now works in plperl. - Stored procedure subs are now given names. The names are not visible in ordinary use, but they make tools like Devel::NYTProf and Devel::Cover much more useful. - Simplified and generalized the subroutine creation code. Now one code path for generating sub source code, not four. Can generate multiple 'use' statements with specific imports (which handles plperl.use_strict currently and can easily be extended to handle a plperl.use_feature=':5.12' in future). - Disallows use of Safe version 2.20 which is broken for PL/Perl. http://rt.perl.org/rt3/Ticket/Display.html?id=72068 - Assorted minor optimizations by pre-growing data structures. Patch from Tim Bunce, reviewed by Alex Hunsaker.
2010-01-27 00:11:56 +01:00
av_extend(rows, processed);
Fix plperl and pltcl error handling per my previous proposal. SPI operations are now run as subtransactions, so that errors in them can be reported as ordinary Perl or Tcl errors and caught by the normal error handling convention of those languages. Also do some minor code cleanup in pltcl.c: extract a large chunk of duplicated code in pltcl_SPI_execute and pltcl_SPI_execute_plan into a shared subroutine.
2004-11-21 22:17:07 +01:00
for (i = 0; i < processed; i++)
{
Generated columns This is an SQL-standard feature that allows creating columns that are computed from expressions rather than assigned, similar to a view or materialized view but on a column basis. This implements one kind of generated column: stored (computed on write). Another kind, virtual (computed on read), is planned for the future, and some room is left for it. Reviewed-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Pavel Stehule <pavel.stehule@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/b151f851-4019-bdb1-699e-ebab07d2f40a@2ndquadrant.com
2019-03-30 08:13:09 +01:00
row = plperl_hash_from_tuple(tuptable->vals[i], tuptable->tupdesc, true);
Further plperl cleanup: be more paranoid about checking the type of data returned from Perl. Consolidate multiple bits of code to convert a Perl hash to a tuple, and drive the conversion off the keys present in the hash rather than the tuple column names, so we detect error if the hash contains keys it shouldn't. (This means keys not in the hash will silently default to NULL, which seems ok to me.) Fix a bunch of reference-count leaks too.
2004-11-23 01:21:24 +01:00
av_push(rows, row);
Redesign query-snapshot timing so that volatile functions in READ COMMITTED mode see a fresh snapshot for each command in the function, rather than using the latest interactive command's snapshot. Also, suppress fresh snapshots as well as CommandCounterIncrement inside STABLE and IMMUTABLE functions, instead using the snapshot taken for the most closely nested regular query. (This behavior is only sane for read-only functions, so the patch also enforces that such functions contain only SELECT commands.) As per my proposal of 6-Sep-2004; I note that I floated essentially the same proposal on 19-Jun-2002, but that discussion tailed off without any action. Since 8.0 seems like the right place to be taking possibly nontrivial backwards compatibility hits, let's get it done now.
2004-09-13 22:10:13 +02:00
}
Adjust plperl to ensure that all strings and hash keys passed to Perl are marked as UTF8 when the database encoding is UTF8. This should avoid inconsistencies like that exhibited in bug #2683 from Vitali Stupin.
2006-10-15 20:56:39 +02:00
hv_store_string(result, "rows",
newRV_noinc((SV *) rows));
Redesign query-snapshot timing so that volatile functions in READ COMMITTED mode see a fresh snapshot for each command in the function, rather than using the latest interactive command's snapshot. Also, suppress fresh snapshots as well as CommandCounterIncrement inside STABLE and IMMUTABLE functions, instead using the snapshot taken for the most closely nested regular query. (This behavior is only sane for read-only functions, so the patch also enforces that such functions contain only SELECT commands.) As per my proposal of 6-Sep-2004; I note that I floated essentially the same proposal on 19-Jun-2002, but that discussion tailed off without any action. Since 8.0 seems like the right place to be taking possibly nontrivial backwards compatibility hits, let's get it done now.
2004-09-13 22:10:13 +02:00
}
SPI_freetuptable(tuptable);
return result;
}
At 2005-05-21 20:18:50 +0530, ams@oryx.com wrote: > > > The second issue is where plperl returns a large result set. I have attached the following seven patches to address this problem: 1. Trivial. Replaces some errant spaces with tabs. 2. Trivial. Fixes the spelling of Jan's name, and gets rid of many inane, useless, annoying, and often misleading comments. Here's a sample: "plperl_init_all() - Initialize all". (I have tried to add some useful comments here and there, and will continue to do so now and again.) 3. Trivial. Splits up some long lines. 4. Converts SRFs in PL/Perl to use a Tuplestore and SFRM_Materialize to return the result set, based on the PL/PgSQL model. There are two major consequences: result sets will spill to disk when they can no longer fit in work_mem; and "select foo_srf()" no longer works. (I didn't lose sleep over the latter, since that form is not valid in PL/PgSQL, and it's not documented in PL/Perl.) 5. Trivial, but important. Fixes use of "undef" instead of undef. This would cause empty functions to fail in bizarre ways. I suspect that there's still another (old) bug here. I'll investigate further. 6. Moves the majority of (4) out into a new plperl_return_next() function, to make it possible to expose the functionality to Perl; cleans up some of the code besides. 7. Add an spi_return_next function for use in Perl code. If you want to apply the patches and try them out, 8-composite.diff is what you should use. (Note: my patches depend upon Andrew's use-strict and %_SHARED patches being applied.) Here's something to try: create or replace function foo() returns setof record as $$ $i = 0; for ("World", "PostgreSQL", "PL/Perl") { spi_return_next({f1=>++$i, f2=>'Hello', f3=>$_}); } return; $$ language plperl; select * from foo() as (f1 integer, f2 text, f3 text); (Many thanks to Andrews Dunstan and Supernews for their help.) Abhijit Menon-Sen
2005-06-04 22:33:06 +02:00
Code review for spi_query/spi_fetchrow patch: handle errors sanely, avoid leaking memory. I would add a regression test for error handling except it seems eval{} can't be used in unprivileged plperl :-(
2005-10-18 19:13:14 +02:00
/*
PL/Perl portability fix: avoid including XSUB.h in plperl.c. In Perl builds that define PERL_IMPLICIT_SYS, XSUB.h defines macros that replace a whole lot of basic libc functions with Perl functions. We can't tolerate that in plperl.c; it breaks at least PG_TRY and probably other stuff. The core idea of this patch is to include XSUB.h only in the .xs files where it's really needed, and to move any code broken by PERL_IMPLICIT_SYS out of the .xs files and into plperl.c. The reason this hasn't been a problem before is that our build techniques did not result in PERL_IMPLICIT_SYS appearing as a #define in PL/Perl, even on some platforms where Perl thinks it is defined. That's about to change in order to fix a nasty portability issue, so we need this work to make the code safe for that. Rather unaccountably, the Perl people chose XSUB.h as the place to provide the versions of the aTHX/aTHX_ macros that are needed by code that's not explicitly aware of the MULTIPLICITY API conventions. Hence, just removing XSUB.h from plperl.c fails miserably. But we can work around that by defining PERL_NO_GET_CONTEXT (which would make the relevant stanza of XSUB.h a no-op anyway). As explained in perlguts.pod, that means we need to add a "dTHX" macro call in every C function that calls a Perl API function. In most of them we just add this at the top; but since the macro fetches the current Perl interpreter pointer, more care is needed in functions that switch the active interpreter. Lack of the macro is easily recognized since it results in bleats about "my_perl" not being defined. (A nice side benefit of this is that it significantly reduces the number of fetches of the current interpreter pointer. On my machine, plperl.so gets more than 10% smaller, and there's probably some performance win too. We could reduce the number of fetches still more by decorating the code with pTHX_/aTHX_ macros to pass the interpreter pointer around, as explained by perlguts.pod; but that's a task for another day.) Formatting note: pgindent seems happy to treat "dTHX;" as a declaration so long as it's the first thing after the left brace, as we'd already observed with respect to the similar macro "dSP;". If you try to put it later in a set of declarations, pgindent puts ugly extra space around it. Having removed XSUB.h from plperl.c, we need only move the support functions for spi_return_next and util_elog (both of which use PG_TRY) out of the .xs files and into plperl.c. This seems sufficient to avoid the known problems caused by PERL_IMPLICIT_SYS, although we could move more code if additional issues emerge. This will need to be back-patched, but first let's see what the buildfarm makes of it. Patch by me, with some help from Ashutosh Sharma Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
2017-07-28 18:25:43 +02:00
* plperl_return_next catches any error and converts it to a Perl error.
* We assume (perhaps without adequate justification) that we need not abort
* the current transaction if the Perl code traps the error.
Code review for spi_query/spi_fetchrow patch: handle errors sanely, avoid leaking memory. I would add a regression test for error handling except it seems eval{} can't be used in unprivileged plperl :-(
2005-10-18 19:13:14 +02:00
*/
At 2005-05-21 20:18:50 +0530, ams@oryx.com wrote: > > > The second issue is where plperl returns a large result set. I have attached the following seven patches to address this problem: 1. Trivial. Replaces some errant spaces with tabs. 2. Trivial. Fixes the spelling of Jan's name, and gets rid of many inane, useless, annoying, and often misleading comments. Here's a sample: "plperl_init_all() - Initialize all". (I have tried to add some useful comments here and there, and will continue to do so now and again.) 3. Trivial. Splits up some long lines. 4. Converts SRFs in PL/Perl to use a Tuplestore and SFRM_Materialize to return the result set, based on the PL/PgSQL model. There are two major consequences: result sets will spill to disk when they can no longer fit in work_mem; and "select foo_srf()" no longer works. (I didn't lose sleep over the latter, since that form is not valid in PL/PgSQL, and it's not documented in PL/Perl.) 5. Trivial, but important. Fixes use of "undef" instead of undef. This would cause empty functions to fail in bizarre ways. I suspect that there's still another (old) bug here. I'll investigate further. 6. Moves the majority of (4) out into a new plperl_return_next() function, to make it possible to expose the functionality to Perl; cleans up some of the code besides. 7. Add an spi_return_next function for use in Perl code. If you want to apply the patches and try them out, 8-composite.diff is what you should use. (Note: my patches depend upon Andrew's use-strict and %_SHARED patches being applied.) Here's something to try: create or replace function foo() returns setof record as $$ $i = 0; for ("World", "PostgreSQL", "PL/Perl") { spi_return_next({f1=>++$i, f2=>'Hello', f3=>$_}); } return; $$ language plperl; select * from foo() as (f1 integer, f2 text, f3 text); (Many thanks to Andrews Dunstan and Supernews for their help.) Abhijit Menon-Sen
2005-06-04 22:33:06 +02:00
void
Code review for spi_query/spi_fetchrow patch: handle errors sanely, avoid leaking memory. I would add a regression test for error handling except it seems eval{} can't be used in unprivileged plperl :-(
2005-10-18 19:13:14 +02:00
plperl_return_next(SV *sv)
PL/Perl portability fix: avoid including XSUB.h in plperl.c. In Perl builds that define PERL_IMPLICIT_SYS, XSUB.h defines macros that replace a whole lot of basic libc functions with Perl functions. We can't tolerate that in plperl.c; it breaks at least PG_TRY and probably other stuff. The core idea of this patch is to include XSUB.h only in the .xs files where it's really needed, and to move any code broken by PERL_IMPLICIT_SYS out of the .xs files and into plperl.c. The reason this hasn't been a problem before is that our build techniques did not result in PERL_IMPLICIT_SYS appearing as a #define in PL/Perl, even on some platforms where Perl thinks it is defined. That's about to change in order to fix a nasty portability issue, so we need this work to make the code safe for that. Rather unaccountably, the Perl people chose XSUB.h as the place to provide the versions of the aTHX/aTHX_ macros that are needed by code that's not explicitly aware of the MULTIPLICITY API conventions. Hence, just removing XSUB.h from plperl.c fails miserably. But we can work around that by defining PERL_NO_GET_CONTEXT (which would make the relevant stanza of XSUB.h a no-op anyway). As explained in perlguts.pod, that means we need to add a "dTHX" macro call in every C function that calls a Perl API function. In most of them we just add this at the top; but since the macro fetches the current Perl interpreter pointer, more care is needed in functions that switch the active interpreter. Lack of the macro is easily recognized since it results in bleats about "my_perl" not being defined. (A nice side benefit of this is that it significantly reduces the number of fetches of the current interpreter pointer. On my machine, plperl.so gets more than 10% smaller, and there's probably some performance win too. We could reduce the number of fetches still more by decorating the code with pTHX_/aTHX_ macros to pass the interpreter pointer around, as explained by perlguts.pod; but that's a task for another day.) Formatting note: pgindent seems happy to treat "dTHX;" as a declaration so long as it's the first thing after the left brace, as we'd already observed with respect to the similar macro "dSP;". If you try to put it later in a set of declarations, pgindent puts ugly extra space around it. Having removed XSUB.h from plperl.c, we need only move the support functions for spi_return_next and util_elog (both of which use PG_TRY) out of the .xs files and into plperl.c. This seems sufficient to avoid the known problems caused by PERL_IMPLICIT_SYS, although we could move more code if additional issues emerge. This will need to be back-patched, but first let's see what the buildfarm makes of it. Patch by me, with some help from Ashutosh Sharma Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
2017-07-28 18:25:43 +02:00
{
MemoryContext oldcontext = CurrentMemoryContext;
Disallow execution of SPI functions during plperl function compilation. Perl can be convinced to execute user-defined code during compilation of a plperl function (or at least a plperlu function). That's not such a big problem as long as the activity is confined within the Perl interpreter, and it's not clear we could do anything about that anyway. However, if such code tries to use plperl's SPI functions, we have a bigger problem. In the first place, those functions are likely to crash because current_call_data->prodesc isn't set up yet. In the second place, because it isn't set up, we lack critical info such as whether the function is supposed to be read-only. And in the third place, this path allows code execution during function validation, which is strongly discouraged because of the potential for security exploits. Hence, reject execution of the SPI functions until compilation is finished. While here, add check_spi_usage_allowed() calls to various functions that hadn't gotten the memo about checking that. I think that perhaps plperl_sv_to_literal may have been intentionally omitted on the grounds that it was safe at the time; but if so, the addition of transforms functionality changed that. The others are more recently added and seem to be flat-out oversights. Per report from Mark Murawski. Back-patch to all supported branches. Discussion: https://postgr.es/m/9acdf918-7fff-4f40-f750-2ffa84f083d2@intellasoft.net
2022-02-25 23:40:21 +01:00
check_spi_usage_allowed();
PL/Perl portability fix: avoid including XSUB.h in plperl.c. In Perl builds that define PERL_IMPLICIT_SYS, XSUB.h defines macros that replace a whole lot of basic libc functions with Perl functions. We can't tolerate that in plperl.c; it breaks at least PG_TRY and probably other stuff. The core idea of this patch is to include XSUB.h only in the .xs files where it's really needed, and to move any code broken by PERL_IMPLICIT_SYS out of the .xs files and into plperl.c. The reason this hasn't been a problem before is that our build techniques did not result in PERL_IMPLICIT_SYS appearing as a #define in PL/Perl, even on some platforms where Perl thinks it is defined. That's about to change in order to fix a nasty portability issue, so we need this work to make the code safe for that. Rather unaccountably, the Perl people chose XSUB.h as the place to provide the versions of the aTHX/aTHX_ macros that are needed by code that's not explicitly aware of the MULTIPLICITY API conventions. Hence, just removing XSUB.h from plperl.c fails miserably. But we can work around that by defining PERL_NO_GET_CONTEXT (which would make the relevant stanza of XSUB.h a no-op anyway). As explained in perlguts.pod, that means we need to add a "dTHX" macro call in every C function that calls a Perl API function. In most of them we just add this at the top; but since the macro fetches the current Perl interpreter pointer, more care is needed in functions that switch the active interpreter. Lack of the macro is easily recognized since it results in bleats about "my_perl" not being defined. (A nice side benefit of this is that it significantly reduces the number of fetches of the current interpreter pointer. On my machine, plperl.so gets more than 10% smaller, and there's probably some performance win too. We could reduce the number of fetches still more by decorating the code with pTHX_/aTHX_ macros to pass the interpreter pointer around, as explained by perlguts.pod; but that's a task for another day.) Formatting note: pgindent seems happy to treat "dTHX;" as a declaration so long as it's the first thing after the left brace, as we'd already observed with respect to the similar macro "dSP;". If you try to put it later in a set of declarations, pgindent puts ugly extra space around it. Having removed XSUB.h from plperl.c, we need only move the support functions for spi_return_next and util_elog (both of which use PG_TRY) out of the .xs files and into plperl.c. This seems sufficient to avoid the known problems caused by PERL_IMPLICIT_SYS, although we could move more code if additional issues emerge. This will need to be back-patched, but first let's see what the buildfarm makes of it. Patch by me, with some help from Ashutosh Sharma Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
2017-07-28 18:25:43 +02:00
PG_TRY();
{
plperl_return_next_internal(sv);
}
PG_CATCH();
{
ErrorData *edata;
/* Must reset elog.c's state */
MemoryContextSwitchTo(oldcontext);
edata = CopyErrorData();
FlushErrorState();
/* Punt the error to Perl */
croak_cstr(edata->message);
}
PG_END_TRY();
}
/*
* plperl_return_next_internal reports any errors in Postgres fashion
* (via ereport).
*/
static void
plperl_return_next_internal(SV *sv)
At 2005-05-21 20:18:50 +0530, ams@oryx.com wrote: > > > The second issue is where plperl returns a large result set. I have attached the following seven patches to address this problem: 1. Trivial. Replaces some errant spaces with tabs. 2. Trivial. Fixes the spelling of Jan's name, and gets rid of many inane, useless, annoying, and often misleading comments. Here's a sample: "plperl_init_all() - Initialize all". (I have tried to add some useful comments here and there, and will continue to do so now and again.) 3. Trivial. Splits up some long lines. 4. Converts SRFs in PL/Perl to use a Tuplestore and SFRM_Materialize to return the result set, based on the PL/PgSQL model. There are two major consequences: result sets will spill to disk when they can no longer fit in work_mem; and "select foo_srf()" no longer works. (I didn't lose sleep over the latter, since that form is not valid in PL/PgSQL, and it's not documented in PL/Perl.) 5. Trivial, but important. Fixes use of "undef" instead of undef. This would cause empty functions to fail in bizarre ways. I suspect that there's still another (old) bug here. I'll investigate further. 6. Moves the majority of (4) out into a new plperl_return_next() function, to make it possible to expose the functionality to Perl; cleans up some of the code besides. 7. Add an spi_return_next function for use in Perl code. If you want to apply the patches and try them out, 8-composite.diff is what you should use. (Note: my patches depend upon Andrew's use-strict and %_SHARED patches being applied.) Here's something to try: create or replace function foo() returns setof record as $$ $i = 0; for ("World", "PostgreSQL", "PL/Perl") { spi_return_next({f1=>++$i, f2=>'Hello', f3=>$_}); } return; $$ language plperl; select * from foo() as (f1 integer, f2 text, f3 text); (Many thanks to Andrews Dunstan and Supernews for their help.) Abhijit Menon-Sen
2005-06-04 22:33:06 +02:00
{
Per a bug report from Theo Schlossnagle, plperl_return_next() leaks memory in the executor's per-query memory context. It also inefficient: it invokes get_call_result_type() and TupleDescGetAttInMetadata() for every call to return_next, rather than invoking them once (per PL/Perl function call) and memoizing the result. This patch makes the following changes: - refactor the code to include all the "per PL/Perl function call" data inside a single struct, "current_call_data". This means we don't need to save and restore N pointers for every recursive call into PL/Perl, we can just save and restore one. - lookup the return type metadata needed by plperl_return_next() once, and then stash it in "current_call_data", so as to avoid doing the lookup for every call to return_next. - create a temporary memory context in which to evaluate the return type's input functions. This memory context is reset for each call to return_next. The patch appears to fix the memory leak, and substantially reduces the overhead imposed by return_next.
2006-01-28 04:28:15 +01:00
plperl_proc_desc *prodesc;
FunctionCallInfo fcinfo;
ReturnSetInfo *rsi;
MemoryContext old_cxt;
At 2005-05-21 20:18:50 +0530, ams@oryx.com wrote: > > > The second issue is where plperl returns a large result set. I have attached the following seven patches to address this problem: 1. Trivial. Replaces some errant spaces with tabs. 2. Trivial. Fixes the spelling of Jan's name, and gets rid of many inane, useless, annoying, and often misleading comments. Here's a sample: "plperl_init_all() - Initialize all". (I have tried to add some useful comments here and there, and will continue to do so now and again.) 3. Trivial. Splits up some long lines. 4. Converts SRFs in PL/Perl to use a Tuplestore and SFRM_Materialize to return the result set, based on the PL/PgSQL model. There are two major consequences: result sets will spill to disk when they can no longer fit in work_mem; and "select foo_srf()" no longer works. (I didn't lose sleep over the latter, since that form is not valid in PL/PgSQL, and it's not documented in PL/Perl.) 5. Trivial, but important. Fixes use of "undef" instead of undef. This would cause empty functions to fail in bizarre ways. I suspect that there's still another (old) bug here. I'll investigate further. 6. Moves the majority of (4) out into a new plperl_return_next() function, to make it possible to expose the functionality to Perl; cleans up some of the code besides. 7. Add an spi_return_next function for use in Perl code. If you want to apply the patches and try them out, 8-composite.diff is what you should use. (Note: my patches depend upon Andrew's use-strict and %_SHARED patches being applied.) Here's something to try: create or replace function foo() returns setof record as $$ $i = 0; for ("World", "PostgreSQL", "PL/Perl") { spi_return_next({f1=>++$i, f2=>'Hello', f3=>$_}); } return; $$ language plperl; select * from foo() as (f1 integer, f2 text, f3 text); (Many thanks to Andrews Dunstan and Supernews for their help.) Abhijit Menon-Sen
2005-06-04 22:33:06 +02:00
if (!sv)
return;
Per a bug report from Theo Schlossnagle, plperl_return_next() leaks memory in the executor's per-query memory context. It also inefficient: it invokes get_call_result_type() and TupleDescGetAttInMetadata() for every call to return_next, rather than invoking them once (per PL/Perl function call) and memoizing the result. This patch makes the following changes: - refactor the code to include all the "per PL/Perl function call" data inside a single struct, "current_call_data". This means we don't need to save and restore N pointers for every recursive call into PL/Perl, we can just save and restore one. - lookup the return type metadata needed by plperl_return_next() once, and then stash it in "current_call_data", so as to avoid doing the lookup for every call to return_next. - create a temporary memory context in which to evaluate the return type's input functions. This memory context is reset for each call to return_next. The patch appears to fix the memory leak, and substantially reduces the overhead imposed by return_next.
2006-01-28 04:28:15 +01:00
prodesc = current_call_data->prodesc;
fcinfo = current_call_data->fcinfo;
rsi = (ReturnSetInfo *) fcinfo->resultinfo;
At 2005-05-21 20:18:50 +0530, ams@oryx.com wrote: > > > The second issue is where plperl returns a large result set. I have attached the following seven patches to address this problem: 1. Trivial. Replaces some errant spaces with tabs. 2. Trivial. Fixes the spelling of Jan's name, and gets rid of many inane, useless, annoying, and often misleading comments. Here's a sample: "plperl_init_all() - Initialize all". (I have tried to add some useful comments here and there, and will continue to do so now and again.) 3. Trivial. Splits up some long lines. 4. Converts SRFs in PL/Perl to use a Tuplestore and SFRM_Materialize to return the result set, based on the PL/PgSQL model. There are two major consequences: result sets will spill to disk when they can no longer fit in work_mem; and "select foo_srf()" no longer works. (I didn't lose sleep over the latter, since that form is not valid in PL/PgSQL, and it's not documented in PL/Perl.) 5. Trivial, but important. Fixes use of "undef" instead of undef. This would cause empty functions to fail in bizarre ways. I suspect that there's still another (old) bug here. I'll investigate further. 6. Moves the majority of (4) out into a new plperl_return_next() function, to make it possible to expose the functionality to Perl; cleans up some of the code besides. 7. Add an spi_return_next function for use in Perl code. If you want to apply the patches and try them out, 8-composite.diff is what you should use. (Note: my patches depend upon Andrew's use-strict and %_SHARED patches being applied.) Here's something to try: create or replace function foo() returns setof record as $$ $i = 0; for ("World", "PostgreSQL", "PL/Perl") { spi_return_next({f1=>++$i, f2=>'Hello', f3=>$_}); } return; $$ language plperl; select * from foo() as (f1 integer, f2 text, f3 text); (Many thanks to Andrews Dunstan and Supernews for their help.) Abhijit Menon-Sen
2005-06-04 22:33:06 +02:00
if (!prodesc->fn_retisset)
ereport(ERROR,
(errcode(ERRCODE_SYNTAX_ERROR),
errmsg("cannot use return_next in a non-SETOF function")));
Per a bug report from Theo Schlossnagle, plperl_return_next() leaks memory in the executor's per-query memory context. It also inefficient: it invokes get_call_result_type() and TupleDescGetAttInMetadata() for every call to return_next, rather than invoking them once (per PL/Perl function call) and memoizing the result. This patch makes the following changes: - refactor the code to include all the "per PL/Perl function call" data inside a single struct, "current_call_data". This means we don't need to save and restore N pointers for every recursive call into PL/Perl, we can just save and restore one. - lookup the return type metadata needed by plperl_return_next() once, and then stash it in "current_call_data", so as to avoid doing the lookup for every call to return_next. - create a temporary memory context in which to evaluate the return type's input functions. This memory context is reset for each call to return_next. The patch appears to fix the memory leak, and substantially reduces the overhead imposed by return_next.
2006-01-28 04:28:15 +01:00
if (!current_call_data->ret_tdesc)
{
TupleDesc tupdesc;
Assert(!current_call_data->tuple_store);
At 2005-05-21 20:18:50 +0530, ams@oryx.com wrote: > > > The second issue is where plperl returns a large result set. I have attached the following seven patches to address this problem: 1. Trivial. Replaces some errant spaces with tabs. 2. Trivial. Fixes the spelling of Jan's name, and gets rid of many inane, useless, annoying, and often misleading comments. Here's a sample: "plperl_init_all() - Initialize all". (I have tried to add some useful comments here and there, and will continue to do so now and again.) 3. Trivial. Splits up some long lines. 4. Converts SRFs in PL/Perl to use a Tuplestore and SFRM_Materialize to return the result set, based on the PL/PgSQL model. There are two major consequences: result sets will spill to disk when they can no longer fit in work_mem; and "select foo_srf()" no longer works. (I didn't lose sleep over the latter, since that form is not valid in PL/PgSQL, and it's not documented in PL/Perl.) 5. Trivial, but important. Fixes use of "undef" instead of undef. This would cause empty functions to fail in bizarre ways. I suspect that there's still another (old) bug here. I'll investigate further. 6. Moves the majority of (4) out into a new plperl_return_next() function, to make it possible to expose the functionality to Perl; cleans up some of the code besides. 7. Add an spi_return_next function for use in Perl code. If you want to apply the patches and try them out, 8-composite.diff is what you should use. (Note: my patches depend upon Andrew's use-strict and %_SHARED patches being applied.) Here's something to try: create or replace function foo() returns setof record as $$ $i = 0; for ("World", "PostgreSQL", "PL/Perl") { spi_return_next({f1=>++$i, f2=>'Hello', f3=>$_}); } return; $$ language plperl; select * from foo() as (f1 integer, f2 text, f3 text); (Many thanks to Andrews Dunstan and Supernews for their help.) Abhijit Menon-Sen
2005-06-04 22:33:06 +02:00
Per a bug report from Theo Schlossnagle, plperl_return_next() leaks memory in the executor's per-query memory context. It also inefficient: it invokes get_call_result_type() and TupleDescGetAttInMetadata() for every call to return_next, rather than invoking them once (per PL/Perl function call) and memoizing the result. This patch makes the following changes: - refactor the code to include all the "per PL/Perl function call" data inside a single struct, "current_call_data". This means we don't need to save and restore N pointers for every recursive call into PL/Perl, we can just save and restore one. - lookup the return type metadata needed by plperl_return_next() once, and then stash it in "current_call_data", so as to avoid doing the lookup for every call to return_next. - create a temporary memory context in which to evaluate the return type's input functions. This memory context is reset for each call to return_next. The patch appears to fix the memory leak, and substantially reduces the overhead imposed by return_next.
2006-01-28 04:28:15 +01:00
/*
* This is the first call to return_next in the current PL/Perl
Support domains over composite types in PL/Perl. In passing, don't insist on rsi->expectedDesc being set unless we actually need it; this allows succeeding in a couple of cases where PL/Perl functions returning setof composite would have failed before, and makes the error message more apropos in other cases. Discussion: https://postgr.es/m/4206.1499798337@sss.pgh.pa.us
2017-10-28 20:02:21 +02:00
* function call, so identify the output tuple type and create a
Tighten coding for non-composite case in plperl's return_next. Coverity complained about this code's practice of using scalar variables as single-element arrays. While that's really just nitpicking, it probably is more readable to declare them as arrays, so let's do that. A more important point is that the code was just blithely assuming that the result tupledesc has exactly one column; if it doesn't, we'd likely get a crash of some sort in tuplestore_putvalues. Since the tupledesc is manufactured outside of plperl, that seems like an uncomfortably long chain of assumptions. We can nail it down at little cost with a sanity check earlier in the function.
2017-07-31 17:33:46 +02:00
* tuplestore to hold the result rows.
Per a bug report from Theo Schlossnagle, plperl_return_next() leaks memory in the executor's per-query memory context. It also inefficient: it invokes get_call_result_type() and TupleDescGetAttInMetadata() for every call to return_next, rather than invoking them once (per PL/Perl function call) and memoizing the result. This patch makes the following changes: - refactor the code to include all the "per PL/Perl function call" data inside a single struct, "current_call_data". This means we don't need to save and restore N pointers for every recursive call into PL/Perl, we can just save and restore one. - lookup the return type metadata needed by plperl_return_next() once, and then stash it in "current_call_data", so as to avoid doing the lookup for every call to return_next. - create a temporary memory context in which to evaluate the return type's input functions. This memory context is reset for each call to return_next. The patch appears to fix the memory leak, and substantially reduces the overhead imposed by return_next.
2006-01-28 04:28:15 +01:00
*/
if (prodesc->fn_retistuple)
Support domains over composite types in PL/Perl. In passing, don't insist on rsi->expectedDesc being set unless we actually need it; this allows succeeding in a couple of cases where PL/Perl functions returning setof composite would have failed before, and makes the error message more apropos in other cases. Discussion: https://postgr.es/m/4206.1499798337@sss.pgh.pa.us
2017-10-28 20:02:21 +02:00
{
TypeFuncClass funcclass;
Oid typid;
funcclass = get_call_result_type(fcinfo, &typid, &tupdesc);
if (funcclass != TYPEFUNC_COMPOSITE &&
funcclass != TYPEFUNC_COMPOSITE_DOMAIN)
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("function returning record called in context "
"that cannot accept type record")));
/* if domain-over-composite, remember the domain's type OID */
if (funcclass == TYPEFUNC_COMPOSITE_DOMAIN)
current_call_data->cdomain_oid = typid;
}
Per a bug report from Theo Schlossnagle, plperl_return_next() leaks memory in the executor's per-query memory context. It also inefficient: it invokes get_call_result_type() and TupleDescGetAttInMetadata() for every call to return_next, rather than invoking them once (per PL/Perl function call) and memoizing the result. This patch makes the following changes: - refactor the code to include all the "per PL/Perl function call" data inside a single struct, "current_call_data". This means we don't need to save and restore N pointers for every recursive call into PL/Perl, we can just save and restore one. - lookup the return type metadata needed by plperl_return_next() once, and then stash it in "current_call_data", so as to avoid doing the lookup for every call to return_next. - create a temporary memory context in which to evaluate the return type's input functions. This memory context is reset for each call to return_next. The patch appears to fix the memory leak, and substantially reduces the overhead imposed by return_next.
2006-01-28 04:28:15 +01:00
else
Tighten coding for non-composite case in plperl's return_next. Coverity complained about this code's practice of using scalar variables as single-element arrays. While that's really just nitpicking, it probably is more readable to declare them as arrays, so let's do that. A more important point is that the code was just blithely assuming that the result tupledesc has exactly one column; if it doesn't, we'd likely get a crash of some sort in tuplestore_putvalues. Since the tupledesc is manufactured outside of plperl, that seems like an uncomfortably long chain of assumptions. We can nail it down at little cost with a sanity check earlier in the function.
2017-07-31 17:33:46 +02:00
{
Per a bug report from Theo Schlossnagle, plperl_return_next() leaks memory in the executor's per-query memory context. It also inefficient: it invokes get_call_result_type() and TupleDescGetAttInMetadata() for every call to return_next, rather than invoking them once (per PL/Perl function call) and memoizing the result. This patch makes the following changes: - refactor the code to include all the "per PL/Perl function call" data inside a single struct, "current_call_data". This means we don't need to save and restore N pointers for every recursive call into PL/Perl, we can just save and restore one. - lookup the return type metadata needed by plperl_return_next() once, and then stash it in "current_call_data", so as to avoid doing the lookup for every call to return_next. - create a temporary memory context in which to evaluate the return type's input functions. This memory context is reset for each call to return_next. The patch appears to fix the memory leak, and substantially reduces the overhead imposed by return_next.
2006-01-28 04:28:15 +01:00
tupdesc = rsi->expectedDesc;
Tighten coding for non-composite case in plperl's return_next. Coverity complained about this code's practice of using scalar variables as single-element arrays. While that's really just nitpicking, it probably is more readable to declare them as arrays, so let's do that. A more important point is that the code was just blithely assuming that the result tupledesc has exactly one column; if it doesn't, we'd likely get a crash of some sort in tuplestore_putvalues. Since the tupledesc is manufactured outside of plperl, that seems like an uncomfortably long chain of assumptions. We can nail it down at little cost with a sanity check earlier in the function.
2017-07-31 17:33:46 +02:00
/* Protect assumption below that we return exactly one column */
if (tupdesc == NULL || tupdesc->natts != 1)
elog(ERROR, "expected single-column result descriptor for non-composite SETOF result");
}
Per a bug report from Theo Schlossnagle, plperl_return_next() leaks memory in the executor's per-query memory context. It also inefficient: it invokes get_call_result_type() and TupleDescGetAttInMetadata() for every call to return_next, rather than invoking them once (per PL/Perl function call) and memoizing the result. This patch makes the following changes: - refactor the code to include all the "per PL/Perl function call" data inside a single struct, "current_call_data". This means we don't need to save and restore N pointers for every recursive call into PL/Perl, we can just save and restore one. - lookup the return type metadata needed by plperl_return_next() once, and then stash it in "current_call_data", so as to avoid doing the lookup for every call to return_next. - create a temporary memory context in which to evaluate the return type's input functions. This memory context is reset for each call to return_next. The patch appears to fix the memory leak, and substantially reduces the overhead imposed by return_next.
2006-01-28 04:28:15 +01:00
/*
* Make sure the tuple_store and ret_tdesc are sufficiently
* long-lived.
*/
old_cxt = MemoryContextSwitchTo(rsi->econtext->ecxt_per_query_memory);
current_call_data->ret_tdesc = CreateTupleDescCopy(tupdesc);
current_call_data->tuple_store =
Be more tense about not creating tuplestores with randomAccess = true unless backwards scan could actually happen. In particular, pass a flag to materialize-mode SRFs that tells them whether they need to require random access. In passing, also suppress unneeded backward-scan overhead for a Portal's holdStore tuplestore. Per my proposal about reducing I/O costs for tuplestores.
2008-10-29 01:00:39 +01:00
tuplestore_begin_heap(rsi->allowedModes & SFRM_Materialize_Random,
false, work_mem);
At 2005-05-21 20:18:50 +0530, ams@oryx.com wrote: > > > The second issue is where plperl returns a large result set. I have attached the following seven patches to address this problem: 1. Trivial. Replaces some errant spaces with tabs. 2. Trivial. Fixes the spelling of Jan's name, and gets rid of many inane, useless, annoying, and often misleading comments. Here's a sample: "plperl_init_all() - Initialize all". (I have tried to add some useful comments here and there, and will continue to do so now and again.) 3. Trivial. Splits up some long lines. 4. Converts SRFs in PL/Perl to use a Tuplestore and SFRM_Materialize to return the result set, based on the PL/PgSQL model. There are two major consequences: result sets will spill to disk when they can no longer fit in work_mem; and "select foo_srf()" no longer works. (I didn't lose sleep over the latter, since that form is not valid in PL/PgSQL, and it's not documented in PL/Perl.) 5. Trivial, but important. Fixes use of "undef" instead of undef. This would cause empty functions to fail in bizarre ways. I suspect that there's still another (old) bug here. I'll investigate further. 6. Moves the majority of (4) out into a new plperl_return_next() function, to make it possible to expose the functionality to Perl; cleans up some of the code besides. 7. Add an spi_return_next function for use in Perl code. If you want to apply the patches and try them out, 8-composite.diff is what you should use. (Note: my patches depend upon Andrew's use-strict and %_SHARED patches being applied.) Here's something to try: create or replace function foo() returns setof record as $$ $i = 0; for ("World", "PostgreSQL", "PL/Perl") { spi_return_next({f1=>++$i, f2=>'Hello', f3=>$_}); } return; $$ language plperl; select * from foo() as (f1 integer, f2 text, f3 text); (Many thanks to Andrews Dunstan and Supernews for their help.) Abhijit Menon-Sen
2005-06-04 22:33:06 +02:00
Per a bug report from Theo Schlossnagle, plperl_return_next() leaks memory in the executor's per-query memory context. It also inefficient: it invokes get_call_result_type() and TupleDescGetAttInMetadata() for every call to return_next, rather than invoking them once (per PL/Perl function call) and memoizing the result. This patch makes the following changes: - refactor the code to include all the "per PL/Perl function call" data inside a single struct, "current_call_data". This means we don't need to save and restore N pointers for every recursive call into PL/Perl, we can just save and restore one. - lookup the return type metadata needed by plperl_return_next() once, and then stash it in "current_call_data", so as to avoid doing the lookup for every call to return_next. - create a temporary memory context in which to evaluate the return type's input functions. This memory context is reset for each call to return_next. The patch appears to fix the memory leak, and substantially reduces the overhead imposed by return_next.
2006-01-28 04:28:15 +01:00
MemoryContextSwitchTo(old_cxt);
}
/*
* Producing the tuple we want to return requires making plenty of
* palloc() allocations that are not cleaned up. Since this function can
* be called many times before the current memory context is reset, we
* need to do those allocations in a temporary context.
*/
if (!current_call_data->tmp_cxt)
At 2005-05-21 20:18:50 +0530, ams@oryx.com wrote: > > > The second issue is where plperl returns a large result set. I have attached the following seven patches to address this problem: 1. Trivial. Replaces some errant spaces with tabs. 2. Trivial. Fixes the spelling of Jan's name, and gets rid of many inane, useless, annoying, and often misleading comments. Here's a sample: "plperl_init_all() - Initialize all". (I have tried to add some useful comments here and there, and will continue to do so now and again.) 3. Trivial. Splits up some long lines. 4. Converts SRFs in PL/Perl to use a Tuplestore and SFRM_Materialize to return the result set, based on the PL/PgSQL model. There are two major consequences: result sets will spill to disk when they can no longer fit in work_mem; and "select foo_srf()" no longer works. (I didn't lose sleep over the latter, since that form is not valid in PL/PgSQL, and it's not documented in PL/Perl.) 5. Trivial, but important. Fixes use of "undef" instead of undef. This would cause empty functions to fail in bizarre ways. I suspect that there's still another (old) bug here. I'll investigate further. 6. Moves the majority of (4) out into a new plperl_return_next() function, to make it possible to expose the functionality to Perl; cleans up some of the code besides. 7. Add an spi_return_next function for use in Perl code. If you want to apply the patches and try them out, 8-composite.diff is what you should use. (Note: my patches depend upon Andrew's use-strict and %_SHARED patches being applied.) Here's something to try: create or replace function foo() returns setof record as $$ $i = 0; for ("World", "PostgreSQL", "PL/Perl") { spi_return_next({f1=>++$i, f2=>'Hello', f3=>$_}); } return; $$ language plperl; select * from foo() as (f1 integer, f2 text, f3 text); (Many thanks to Andrews Dunstan and Supernews for their help.) Abhijit Menon-Sen
2005-06-04 22:33:06 +02:00
{
Per a bug report from Theo Schlossnagle, plperl_return_next() leaks memory in the executor's per-query memory context. It also inefficient: it invokes get_call_result_type() and TupleDescGetAttInMetadata() for every call to return_next, rather than invoking them once (per PL/Perl function call) and memoizing the result. This patch makes the following changes: - refactor the code to include all the "per PL/Perl function call" data inside a single struct, "current_call_data". This means we don't need to save and restore N pointers for every recursive call into PL/Perl, we can just save and restore one. - lookup the return type metadata needed by plperl_return_next() once, and then stash it in "current_call_data", so as to avoid doing the lookup for every call to return_next. - create a temporary memory context in which to evaluate the return type's input functions. This memory context is reset for each call to return_next. The patch appears to fix the memory leak, and substantially reduces the overhead imposed by return_next.
2006-01-28 04:28:15 +01:00
current_call_data->tmp_cxt =
Fix up Perl-to-Postgres datatype conversions in pl/perl. This patch restores the pre-9.1 behavior that pl/perl functions returning VOID ignore the result value of their last Perl statement. 9.1.0 unintentionally threw an error if the last statement returned a reference, as reported by Amit Khandekar. Also, make sure it works to return a string value for a composite type, so long as the string meets the type's input format. We already allowed the equivalent behavior for arrays, so it seems inconsistent to not allow it for composites. In addition, ensure we throw errors for attempts to return arrays or hashes when the function's declared result type is not an array or composite type, respectively. Pre-9.1 versions rather uselessly returned strings like ARRAY(0x221a9a0) or HASH(0x221aa90), while 9.1.0 threw an error for the hash case and returned a garbage value for the array case. Also, clean up assorted grotty coding in Perl array conversion, including use of a session-lifespan memory context to accumulate the array value (resulting in session-lifespan memory leak on error), failure to apply the declared typmod if any, and failure to detect some cases of non-rectangular multi-dimensional arrays. Alex Hunsaker and Tom Lane
2011-10-14 00:02:43 +02:00
AllocSetContextCreate(CurrentMemoryContext,
Per a bug report from Theo Schlossnagle, plperl_return_next() leaks memory in the executor's per-query memory context. It also inefficient: it invokes get_call_result_type() and TupleDescGetAttInMetadata() for every call to return_next, rather than invoking them once (per PL/Perl function call) and memoizing the result. This patch makes the following changes: - refactor the code to include all the "per PL/Perl function call" data inside a single struct, "current_call_data". This means we don't need to save and restore N pointers for every recursive call into PL/Perl, we can just save and restore one. - lookup the return type metadata needed by plperl_return_next() once, and then stash it in "current_call_data", so as to avoid doing the lookup for every call to return_next. - create a temporary memory context in which to evaluate the return type's input functions. This memory context is reset for each call to return_next. The patch appears to fix the memory leak, and substantially reduces the overhead imposed by return_next.
2006-01-28 04:28:15 +01:00
"PL/Perl return_next temporary cxt",
Add macros to make AllocSetContextCreate() calls simpler and safer. I found that half a dozen (nearly 5%) of our AllocSetContextCreate calls had typos in the context-sizing parameters. While none of these led to especially significant problems, they did create minor inefficiencies, and it's now clear that expecting people to copy-and-paste those calls accurately is not a great idea. Let's reduce the risk of future errors by introducing single macros that encapsulate the common use-cases. Three such macros are enough to cover all but two special-purpose contexts; those two calls can be left as-is, I think. While this patch doesn't in itself improve matters for third-party extensions, it doesn't break anything for them either, and they can gradually adopt the simplified notation over time. In passing, change TopMemoryContext to use the default allocation parameters. Formerly it could only be extended 8K at a time. That was probably reasonable when this code was written; but nowadays we create many more contexts than we did then, so that it's not unusual to have a couple hundred K in TopMemoryContext, even without considering various dubious code that sticks other things there. There seems no good reason not to let it use growing blocks like most other contexts. Back-patch to 9.6, mostly because that's still close enough to HEAD that it's easy to do so, and keeping the branches in sync can be expected to avoid some future back-patching pain. The bugs fixed by these changes don't seem to be significant enough to justify fixing them further back. Discussion: <21072.1472321324@sss.pgh.pa.us>
2016-08-27 23:50:38 +02:00
ALLOCSET_DEFAULT_SIZES);
Per a bug report from Theo Schlossnagle, plperl_return_next() leaks memory in the executor's per-query memory context. It also inefficient: it invokes get_call_result_type() and TupleDescGetAttInMetadata() for every call to return_next, rather than invoking them once (per PL/Perl function call) and memoizing the result. This patch makes the following changes: - refactor the code to include all the "per PL/Perl function call" data inside a single struct, "current_call_data". This means we don't need to save and restore N pointers for every recursive call into PL/Perl, we can just save and restore one. - lookup the return type metadata needed by plperl_return_next() once, and then stash it in "current_call_data", so as to avoid doing the lookup for every call to return_next. - create a temporary memory context in which to evaluate the return type's input functions. This memory context is reset for each call to return_next. The patch appears to fix the memory leak, and substantially reduces the overhead imposed by return_next.
2006-01-28 04:28:15 +01:00
}
old_cxt = MemoryContextSwitchTo(current_call_data->tmp_cxt);
At 2005-05-21 20:18:50 +0530, ams@oryx.com wrote: > > > The second issue is where plperl returns a large result set. I have attached the following seven patches to address this problem: 1. Trivial. Replaces some errant spaces with tabs. 2. Trivial. Fixes the spelling of Jan's name, and gets rid of many inane, useless, annoying, and often misleading comments. Here's a sample: "plperl_init_all() - Initialize all". (I have tried to add some useful comments here and there, and will continue to do so now and again.) 3. Trivial. Splits up some long lines. 4. Converts SRFs in PL/Perl to use a Tuplestore and SFRM_Materialize to return the result set, based on the PL/PgSQL model. There are two major consequences: result sets will spill to disk when they can no longer fit in work_mem; and "select foo_srf()" no longer works. (I didn't lose sleep over the latter, since that form is not valid in PL/PgSQL, and it's not documented in PL/Perl.) 5. Trivial, but important. Fixes use of "undef" instead of undef. This would cause empty functions to fail in bizarre ways. I suspect that there's still another (old) bug here. I'll investigate further. 6. Moves the majority of (4) out into a new plperl_return_next() function, to make it possible to expose the functionality to Perl; cleans up some of the code besides. 7. Add an spi_return_next function for use in Perl code. If you want to apply the patches and try them out, 8-composite.diff is what you should use. (Note: my patches depend upon Andrew's use-strict and %_SHARED patches being applied.) Here's something to try: create or replace function foo() returns setof record as $$ $i = 0; for ("World", "PostgreSQL", "PL/Perl") { spi_return_next({f1=>++$i, f2=>'Hello', f3=>$_}); } return; $$ language plperl; select * from foo() as (f1 integer, f2 text, f3 text); (Many thanks to Andrews Dunstan and Supernews for their help.) Abhijit Menon-Sen
2005-06-04 22:33:06 +02:00
Per a bug report from Theo Schlossnagle, plperl_return_next() leaks memory in the executor's per-query memory context. It also inefficient: it invokes get_call_result_type() and TupleDescGetAttInMetadata() for every call to return_next, rather than invoking them once (per PL/Perl function call) and memoizing the result. This patch makes the following changes: - refactor the code to include all the "per PL/Perl function call" data inside a single struct, "current_call_data". This means we don't need to save and restore N pointers for every recursive call into PL/Perl, we can just save and restore one. - lookup the return type metadata needed by plperl_return_next() once, and then stash it in "current_call_data", so as to avoid doing the lookup for every call to return_next. - create a temporary memory context in which to evaluate the return type's input functions. This memory context is reset for each call to return_next. The patch appears to fix the memory leak, and substantially reduces the overhead imposed by return_next.
2006-01-28 04:28:15 +01:00
if (prodesc->fn_retistuple)
{
Add a new tuplestore API function, tuplestore_putvalues(). This is identical to tuplestore_puttuple(), except it operates on arrays of Datums + nulls rather than a fully-formed HeapTuple. In several places that use the tuplestore API, this means we can avoid creating a HeapTuple altogether, saving a copy.
2008-03-25 20:26:54 +01:00
HeapTuple tuple;
Fix up Perl-to-Postgres datatype conversions in pl/perl. This patch restores the pre-9.1 behavior that pl/perl functions returning VOID ignore the result value of their last Perl statement. 9.1.0 unintentionally threw an error if the last statement returned a reference, as reported by Amit Khandekar. Also, make sure it works to return a string value for a composite type, so long as the string meets the type's input format. We already allowed the equivalent behavior for arrays, so it seems inconsistent to not allow it for composites. In addition, ensure we throw errors for attempts to return arrays or hashes when the function's declared result type is not an array or composite type, respectively. Pre-9.1 versions rather uselessly returned strings like ARRAY(0x221a9a0) or HASH(0x221aa90), while 9.1.0 threw an error for the hash case and returned a garbage value for the array case. Also, clean up assorted grotty coding in Perl array conversion, including use of a session-lifespan memory context to accumulate the array value (resulting in session-lifespan memory leak on error), failure to apply the declared typmod if any, and failure to detect some cases of non-rectangular multi-dimensional arrays. Alex Hunsaker and Tom Lane
2011-10-14 00:02:43 +02:00
if (!(SvOK(sv) && SvROK(sv) && SvTYPE(SvRV(sv)) == SVt_PVHV))
ereport(ERROR,
(errcode(ERRCODE_DATATYPE_MISMATCH),
errmsg("SETOF-composite-returning PL/Perl function "
"must call return_next with reference to hash")));
Per a bug report from Theo Schlossnagle, plperl_return_next() leaks memory in the executor's per-query memory context. It also inefficient: it invokes get_call_result_type() and TupleDescGetAttInMetadata() for every call to return_next, rather than invoking them once (per PL/Perl function call) and memoizing the result. This patch makes the following changes: - refactor the code to include all the "per PL/Perl function call" data inside a single struct, "current_call_data". This means we don't need to save and restore N pointers for every recursive call into PL/Perl, we can just save and restore one. - lookup the return type metadata needed by plperl_return_next() once, and then stash it in "current_call_data", so as to avoid doing the lookup for every call to return_next. - create a temporary memory context in which to evaluate the return type's input functions. This memory context is reset for each call to return_next. The patch appears to fix the memory leak, and substantially reduces the overhead imposed by return_next.
2006-01-28 04:28:15 +01:00
tuple = plperl_build_tuple_result((HV *) SvRV(sv),
Fix up Perl-to-Postgres datatype conversions in pl/perl. This patch restores the pre-9.1 behavior that pl/perl functions returning VOID ignore the result value of their last Perl statement. 9.1.0 unintentionally threw an error if the last statement returned a reference, as reported by Amit Khandekar. Also, make sure it works to return a string value for a composite type, so long as the string meets the type's input format. We already allowed the equivalent behavior for arrays, so it seems inconsistent to not allow it for composites. In addition, ensure we throw errors for attempts to return arrays or hashes when the function's declared result type is not an array or composite type, respectively. Pre-9.1 versions rather uselessly returned strings like ARRAY(0x221a9a0) or HASH(0x221aa90), while 9.1.0 threw an error for the hash case and returned a garbage value for the array case. Also, clean up assorted grotty coding in Perl array conversion, including use of a session-lifespan memory context to accumulate the array value (resulting in session-lifespan memory leak on error), failure to apply the declared typmod if any, and failure to detect some cases of non-rectangular multi-dimensional arrays. Alex Hunsaker and Tom Lane
2011-10-14 00:02:43 +02:00
current_call_data->ret_tdesc);
Support domains over composite types in PL/Perl. In passing, don't insist on rsi->expectedDesc being set unless we actually need it; this allows succeeding in a couple of cases where PL/Perl functions returning setof composite would have failed before, and makes the error message more apropos in other cases. Discussion: https://postgr.es/m/4206.1499798337@sss.pgh.pa.us
2017-10-28 20:02:21 +02:00
if (OidIsValid(current_call_data->cdomain_oid))
domain_check(HeapTupleGetDatum(tuple), false,
current_call_data->cdomain_oid,
&current_call_data->cdomain_info,
rsi->econtext->ecxt_per_query_memory);
Add a new tuplestore API function, tuplestore_putvalues(). This is identical to tuplestore_puttuple(), except it operates on arrays of Datums + nulls rather than a fully-formed HeapTuple. In several places that use the tuplestore API, this means we can avoid creating a HeapTuple altogether, saving a copy.
2008-03-25 20:26:54 +01:00
tuplestore_puttuple(current_call_data->tuple_store, tuple);
At 2005-05-21 20:18:50 +0530, ams@oryx.com wrote: > > > The second issue is where plperl returns a large result set. I have attached the following seven patches to address this problem: 1. Trivial. Replaces some errant spaces with tabs. 2. Trivial. Fixes the spelling of Jan's name, and gets rid of many inane, useless, annoying, and often misleading comments. Here's a sample: "plperl_init_all() - Initialize all". (I have tried to add some useful comments here and there, and will continue to do so now and again.) 3. Trivial. Splits up some long lines. 4. Converts SRFs in PL/Perl to use a Tuplestore and SFRM_Materialize to return the result set, based on the PL/PgSQL model. There are two major consequences: result sets will spill to disk when they can no longer fit in work_mem; and "select foo_srf()" no longer works. (I didn't lose sleep over the latter, since that form is not valid in PL/PgSQL, and it's not documented in PL/Perl.) 5. Trivial, but important. Fixes use of "undef" instead of undef. This would cause empty functions to fail in bizarre ways. I suspect that there's still another (old) bug here. I'll investigate further. 6. Moves the majority of (4) out into a new plperl_return_next() function, to make it possible to expose the functionality to Perl; cleans up some of the code besides. 7. Add an spi_return_next function for use in Perl code. If you want to apply the patches and try them out, 8-composite.diff is what you should use. (Note: my patches depend upon Andrew's use-strict and %_SHARED patches being applied.) Here's something to try: create or replace function foo() returns setof record as $$ $i = 0; for ("World", "PostgreSQL", "PL/Perl") { spi_return_next({f1=>++$i, f2=>'Hello', f3=>$_}); } return; $$ language plperl; select * from foo() as (f1 integer, f2 text, f3 text); (Many thanks to Andrews Dunstan and Supernews for their help.) Abhijit Menon-Sen
2005-06-04 22:33:06 +02:00
}
SQL procedures This adds a new object type "procedure" that is similar to a function but does not have a return type and is invoked by the new CALL statement instead of SELECT or similar. This implementation is aligned with the SQL standard and compatible with or similar to other SQL implementations. This commit adds new commands CALL, CREATE/ALTER/DROP PROCEDURE, as well as ALTER/DROP ROUTINE that can refer to either a function or a procedure (or an aggregate function, as an extension to SQL). There is also support for procedures in various utility commands such as COMMENT and GRANT, as well as support in pg_dump and psql. Support for defining procedures is available in all the languages supplied by the core distribution. While this commit is mainly syntax sugar around existing functionality, future features will rely on having procedures as a separate object type. Reviewed-by: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
2017-11-30 14:46:13 +01:00
else if (prodesc->result_oid)
At 2005-05-21 20:18:50 +0530, ams@oryx.com wrote: > > > The second issue is where plperl returns a large result set. I have attached the following seven patches to address this problem: 1. Trivial. Replaces some errant spaces with tabs. 2. Trivial. Fixes the spelling of Jan's name, and gets rid of many inane, useless, annoying, and often misleading comments. Here's a sample: "plperl_init_all() - Initialize all". (I have tried to add some useful comments here and there, and will continue to do so now and again.) 3. Trivial. Splits up some long lines. 4. Converts SRFs in PL/Perl to use a Tuplestore and SFRM_Materialize to return the result set, based on the PL/PgSQL model. There are two major consequences: result sets will spill to disk when they can no longer fit in work_mem; and "select foo_srf()" no longer works. (I didn't lose sleep over the latter, since that form is not valid in PL/PgSQL, and it's not documented in PL/Perl.) 5. Trivial, but important. Fixes use of "undef" instead of undef. This would cause empty functions to fail in bizarre ways. I suspect that there's still another (old) bug here. I'll investigate further. 6. Moves the majority of (4) out into a new plperl_return_next() function, to make it possible to expose the functionality to Perl; cleans up some of the code besides. 7. Add an spi_return_next function for use in Perl code. If you want to apply the patches and try them out, 8-composite.diff is what you should use. (Note: my patches depend upon Andrew's use-strict and %_SHARED patches being applied.) Here's something to try: create or replace function foo() returns setof record as $$ $i = 0; for ("World", "PostgreSQL", "PL/Perl") { spi_return_next({f1=>++$i, f2=>'Hello', f3=>$_}); } return; $$ language plperl; select * from foo() as (f1 integer, f2 text, f3 text); (Many thanks to Andrews Dunstan and Supernews for their help.) Abhijit Menon-Sen
2005-06-04 22:33:06 +02:00
{
Tighten coding for non-composite case in plperl's return_next. Coverity complained about this code's practice of using scalar variables as single-element arrays. While that's really just nitpicking, it probably is more readable to declare them as arrays, so let's do that. A more important point is that the code was just blithely assuming that the result tupledesc has exactly one column; if it doesn't, we'd likely get a crash of some sort in tuplestore_putvalues. Since the tupledesc is manufactured outside of plperl, that seems like an uncomfortably long chain of assumptions. We can nail it down at little cost with a sanity check earlier in the function.
2017-07-31 17:33:46 +02:00
Datum ret[1];
bool isNull[1];
At 2005-05-21 20:18:50 +0530, ams@oryx.com wrote: > > > The second issue is where plperl returns a large result set. I have attached the following seven patches to address this problem: 1. Trivial. Replaces some errant spaces with tabs. 2. Trivial. Fixes the spelling of Jan's name, and gets rid of many inane, useless, annoying, and often misleading comments. Here's a sample: "plperl_init_all() - Initialize all". (I have tried to add some useful comments here and there, and will continue to do so now and again.) 3. Trivial. Splits up some long lines. 4. Converts SRFs in PL/Perl to use a Tuplestore and SFRM_Materialize to return the result set, based on the PL/PgSQL model. There are two major consequences: result sets will spill to disk when they can no longer fit in work_mem; and "select foo_srf()" no longer works. (I didn't lose sleep over the latter, since that form is not valid in PL/PgSQL, and it's not documented in PL/Perl.) 5. Trivial, but important. Fixes use of "undef" instead of undef. This would cause empty functions to fail in bizarre ways. I suspect that there's still another (old) bug here. I'll investigate further. 6. Moves the majority of (4) out into a new plperl_return_next() function, to make it possible to expose the functionality to Perl; cleans up some of the code besides. 7. Add an spi_return_next function for use in Perl code. If you want to apply the patches and try them out, 8-composite.diff is what you should use. (Note: my patches depend upon Andrew's use-strict and %_SHARED patches being applied.) Here's something to try: create or replace function foo() returns setof record as $$ $i = 0; for ("World", "PostgreSQL", "PL/Perl") { spi_return_next({f1=>++$i, f2=>'Hello', f3=>$_}); } return; $$ language plperl; select * from foo() as (f1 integer, f2 text, f3 text); (Many thanks to Andrews Dunstan and Supernews for their help.) Abhijit Menon-Sen
2005-06-04 22:33:06 +02:00
Tighten coding for non-composite case in plperl's return_next. Coverity complained about this code's practice of using scalar variables as single-element arrays. While that's really just nitpicking, it probably is more readable to declare them as arrays, so let's do that. A more important point is that the code was just blithely assuming that the result tupledesc has exactly one column; if it doesn't, we'd likely get a crash of some sort in tuplestore_putvalues. Since the tupledesc is manufactured outside of plperl, that seems like an uncomfortably long chain of assumptions. We can nail it down at little cost with a sanity check earlier in the function.
2017-07-31 17:33:46 +02:00
ret[0] = plperl_sv_to_datum(sv,
prodesc->result_oid,
-1,
fcinfo,
&prodesc->result_in_func,
prodesc->result_typioparam,
&isNull[0]);
At 2005-05-21 20:18:50 +0530, ams@oryx.com wrote: > > > The second issue is where plperl returns a large result set. I have attached the following seven patches to address this problem: 1. Trivial. Replaces some errant spaces with tabs. 2. Trivial. Fixes the spelling of Jan's name, and gets rid of many inane, useless, annoying, and often misleading comments. Here's a sample: "plperl_init_all() - Initialize all". (I have tried to add some useful comments here and there, and will continue to do so now and again.) 3. Trivial. Splits up some long lines. 4. Converts SRFs in PL/Perl to use a Tuplestore and SFRM_Materialize to return the result set, based on the PL/PgSQL model. There are two major consequences: result sets will spill to disk when they can no longer fit in work_mem; and "select foo_srf()" no longer works. (I didn't lose sleep over the latter, since that form is not valid in PL/PgSQL, and it's not documented in PL/Perl.) 5. Trivial, but important. Fixes use of "undef" instead of undef. This would cause empty functions to fail in bizarre ways. I suspect that there's still another (old) bug here. I'll investigate further. 6. Moves the majority of (4) out into a new plperl_return_next() function, to make it possible to expose the functionality to Perl; cleans up some of the code besides. 7. Add an spi_return_next function for use in Perl code. If you want to apply the patches and try them out, 8-composite.diff is what you should use. (Note: my patches depend upon Andrew's use-strict and %_SHARED patches being applied.) Here's something to try: create or replace function foo() returns setof record as $$ $i = 0; for ("World", "PostgreSQL", "PL/Perl") { spi_return_next({f1=>++$i, f2=>'Hello', f3=>$_}); } return; $$ language plperl; select * from foo() as (f1 integer, f2 text, f3 text); (Many thanks to Andrews Dunstan and Supernews for their help.) Abhijit Menon-Sen
2005-06-04 22:33:06 +02:00
Add a new tuplestore API function, tuplestore_putvalues(). This is identical to tuplestore_puttuple(), except it operates on arrays of Datums + nulls rather than a fully-formed HeapTuple. In several places that use the tuplestore API, this means we can avoid creating a HeapTuple altogether, saving a copy.
2008-03-25 20:26:54 +01:00
tuplestore_putvalues(current_call_data->tuple_store,
current_call_data->ret_tdesc,
Tighten coding for non-composite case in plperl's return_next. Coverity complained about this code's practice of using scalar variables as single-element arrays. While that's really just nitpicking, it probably is more readable to declare them as arrays, so let's do that. A more important point is that the code was just blithely assuming that the result tupledesc has exactly one column; if it doesn't, we'd likely get a crash of some sort in tuplestore_putvalues. Since the tupledesc is manufactured outside of plperl, that seems like an uncomfortably long chain of assumptions. We can nail it down at little cost with a sanity check earlier in the function.
2017-07-31 17:33:46 +02:00
ret, isNull);
At 2005-05-21 20:18:50 +0530, ams@oryx.com wrote: > > > The second issue is where plperl returns a large result set. I have attached the following seven patches to address this problem: 1. Trivial. Replaces some errant spaces with tabs. 2. Trivial. Fixes the spelling of Jan's name, and gets rid of many inane, useless, annoying, and often misleading comments. Here's a sample: "plperl_init_all() - Initialize all". (I have tried to add some useful comments here and there, and will continue to do so now and again.) 3. Trivial. Splits up some long lines. 4. Converts SRFs in PL/Perl to use a Tuplestore and SFRM_Materialize to return the result set, based on the PL/PgSQL model. There are two major consequences: result sets will spill to disk when they can no longer fit in work_mem; and "select foo_srf()" no longer works. (I didn't lose sleep over the latter, since that form is not valid in PL/PgSQL, and it's not documented in PL/Perl.) 5. Trivial, but important. Fixes use of "undef" instead of undef. This would cause empty functions to fail in bizarre ways. I suspect that there's still another (old) bug here. I'll investigate further. 6. Moves the majority of (4) out into a new plperl_return_next() function, to make it possible to expose the functionality to Perl; cleans up some of the code besides. 7. Add an spi_return_next function for use in Perl code. If you want to apply the patches and try them out, 8-composite.diff is what you should use. (Note: my patches depend upon Andrew's use-strict and %_SHARED patches being applied.) Here's something to try: create or replace function foo() returns setof record as $$ $i = 0; for ("World", "PostgreSQL", "PL/Perl") { spi_return_next({f1=>++$i, f2=>'Hello', f3=>$_}); } return; $$ language plperl; select * from foo() as (f1 integer, f2 text, f3 text); (Many thanks to Andrews Dunstan and Supernews for their help.) Abhijit Menon-Sen
2005-06-04 22:33:06 +02:00
}
Previous fix for temporary file management broke returning a set from PL/pgSQL function within an exception handler. Make sure we use the right resource owner when we create the tuplestore to hold returned tuples. Simplify tuplestore API so that the caller doesn't need to be in the right memory context when calling tuplestore_put* functions. tuplestore.c automatically switches to the memory context used when the tuplestore was created. Tuplesort was already modified like this earlier. This patch also removes the now useless MemoryContextSwitch calls from callers. Report by Aleksei on pgsql-bugs on Dec 22 2009. Backpatch to 8.1, like the previous patch that broke this.
2009-12-29 18:40:59 +01:00
MemoryContextSwitchTo(old_cxt);
Per a bug report from Theo Schlossnagle, plperl_return_next() leaks memory in the executor's per-query memory context. It also inefficient: it invokes get_call_result_type() and TupleDescGetAttInMetadata() for every call to return_next, rather than invoking them once (per PL/Perl function call) and memoizing the result. This patch makes the following changes: - refactor the code to include all the "per PL/Perl function call" data inside a single struct, "current_call_data". This means we don't need to save and restore N pointers for every recursive call into PL/Perl, we can just save and restore one. - lookup the return type metadata needed by plperl_return_next() once, and then stash it in "current_call_data", so as to avoid doing the lookup for every call to return_next. - create a temporary memory context in which to evaluate the return type's input functions. This memory context is reset for each call to return_next. The patch appears to fix the memory leak, and substantially reduces the overhead imposed by return_next.
2006-01-28 04:28:15 +01:00
MemoryContextReset(current_call_data->tmp_cxt);
At 2005-05-21 20:18:50 +0530, ams@oryx.com wrote: > > > The second issue is where plperl returns a large result set. I have attached the following seven patches to address this problem: 1. Trivial. Replaces some errant spaces with tabs. 2. Trivial. Fixes the spelling of Jan's name, and gets rid of many inane, useless, annoying, and often misleading comments. Here's a sample: "plperl_init_all() - Initialize all". (I have tried to add some useful comments here and there, and will continue to do so now and again.) 3. Trivial. Splits up some long lines. 4. Converts SRFs in PL/Perl to use a Tuplestore and SFRM_Materialize to return the result set, based on the PL/PgSQL model. There are two major consequences: result sets will spill to disk when they can no longer fit in work_mem; and "select foo_srf()" no longer works. (I didn't lose sleep over the latter, since that form is not valid in PL/PgSQL, and it's not documented in PL/Perl.) 5. Trivial, but important. Fixes use of "undef" instead of undef. This would cause empty functions to fail in bizarre ways. I suspect that there's still another (old) bug here. I'll investigate further. 6. Moves the majority of (4) out into a new plperl_return_next() function, to make it possible to expose the functionality to Perl; cleans up some of the code besides. 7. Add an spi_return_next function for use in Perl code. If you want to apply the patches and try them out, 8-composite.diff is what you should use. (Note: my patches depend upon Andrew's use-strict and %_SHARED patches being applied.) Here's something to try: create or replace function foo() returns setof record as $$ $i = 0; for ("World", "PostgreSQL", "PL/Perl") { spi_return_next({f1=>++$i, f2=>'Hello', f3=>$_}); } return; $$ language plperl; select * from foo() as (f1 integer, f2 text, f3 text); (Many thanks to Andrews Dunstan and Supernews for their help.) Abhijit Menon-Sen
2005-06-04 22:33:06 +02:00
}
The attached patch implements spi_query() and spi_fetchrow() functions for PL/Perl, to avoid loading the entire result set into memory as the existing spi_exec_query() function does. Here's how one might use the new functions: $x = spi_query("select ..."); while (defined ($y = spi_fetchrow($x))) { ... return_next(...); } The changes do not affect the spi_exec_query() interface in any way. Abhijit Menon-Sen
2005-07-10 17:19:43 +02:00
SV *
plperl_spi_query(char *query)
{
SV *cursor;
Code review for spi_query/spi_fetchrow patch: handle errors sanely, avoid leaking memory. I would add a regression test for error handling except it seems eval{} can't be used in unprivileged plperl :-(
2005-10-18 19:13:14 +02:00
/*
* Execute the query inside a sub-transaction, so we can cope with errors
* sanely
*/
The attached patch implements spi_query() and spi_fetchrow() functions for PL/Perl, to avoid loading the entire result set into memory as the existing spi_exec_query() function does. Here's how one might use the new functions: $x = spi_query("select ..."); while (defined ($y = spi_fetchrow($x))) { ... return_next(...); } The changes do not affect the spi_exec_query() interface in any way. Abhijit Menon-Sen
2005-07-10 17:19:43 +02:00
MemoryContext oldcontext = CurrentMemoryContext;
ResourceOwner oldowner = CurrentResourceOwner;
Add plperl.on_perl_init setting to provide for initializing the perl library on load. Also, handle END blocks in plperl. Database access is disallowed during both these operations, although it might be allowed in END blocks in future. Patch from Tim Bunce.
2010-01-30 02:46:57 +01:00
check_spi_usage_allowed();
The attached patch implements spi_query() and spi_fetchrow() functions for PL/Perl, to avoid loading the entire result set into memory as the existing spi_exec_query() function does. Here's how one might use the new functions: $x = spi_query("select ..."); while (defined ($y = spi_fetchrow($x))) { ... return_next(...); } The changes do not affect the spi_exec_query() interface in any way. Abhijit Menon-Sen
2005-07-10 17:19:43 +02:00
BeginInternalSubTransaction(NULL);
Code review for spi_query/spi_fetchrow patch: handle errors sanely, avoid leaking memory. I would add a regression test for error handling except it seems eval{} can't be used in unprivileged plperl :-(
2005-10-18 19:13:14 +02:00
/* Want to run inside function's memory context */
The attached patch implements spi_query() and spi_fetchrow() functions for PL/Perl, to avoid loading the entire result set into memory as the existing spi_exec_query() function does. Here's how one might use the new functions: $x = spi_query("select ..."); while (defined ($y = spi_fetchrow($x))) { ... return_next(...); } The changes do not affect the spi_exec_query() interface in any way. Abhijit Menon-Sen
2005-07-10 17:19:43 +02:00
MemoryContextSwitchTo(oldcontext);
PG_TRY();
{
Redesign the plancache mechanism for more flexibility and efficiency. Rewrite plancache.c so that a "cached plan" (which is rather a misnomer at this point) can support generation of custom, parameter-value-dependent plans, and can make an intelligent choice between using custom plans and the traditional generic-plan approach. The specific choice algorithm implemented here can probably be improved in future, but this commit is all about getting the mechanism in place, not the policy. In addition, restructure the API to greatly reduce the amount of extraneous data copying needed. The main compromise needed to make that possible was to split the initial creation of a CachedPlanSource into two steps. It's worth noting in particular that SPI_saveplan is now deprecated in favor of SPI_keepplan, which accomplishes the same end result with zero data copying, and no need to then spend even more cycles throwing away the original SPIPlan. The risk of long-term memory leaks while manipulating SPIPlans has also been greatly reduced. Most of this improvement is based on use of the recently-added MemoryContextSetParent primitive.
2011-09-16 06:42:53 +02:00
SPIPlanPtr plan;
Prepared queries for PLPerl, plus fixing a small plperl memory leak. Patch and docs from Dmitry Karasik, slightly editorialised.
2006-03-05 17:40:51 +01:00
Portal portal;
The attached patch implements spi_query() and spi_fetchrow() functions for PL/Perl, to avoid loading the entire result set into memory as the existing spi_exec_query() function does. Here's how one might use the new functions: $x = spi_query("select ..."); while (defined ($y = spi_fetchrow($x))) { ... return_next(...); } The changes do not affect the spi_exec_query() interface in any way. Abhijit Menon-Sen
2005-07-10 17:19:43 +02:00
Add checks for valid encoding of query strings passed to SPI by plperl.
2010-03-09 03:48:33 +01:00
/* Make sure the query is validly encoded */
pg_verifymbstr(query, strlen(query), false);
Code review for spi_query/spi_fetchrow patch: handle errors sanely, avoid leaking memory. I would add a regression test for error handling except it seems eval{} can't be used in unprivileged plperl :-(
2005-10-18 19:13:14 +02:00
/* Create a cursor for the query */
The attached patch implements spi_query() and spi_fetchrow() functions for PL/Perl, to avoid loading the entire result set into memory as the existing spi_exec_query() function does. Here's how one might use the new functions: $x = spi_query("select ..."); while (defined ($y = spi_fetchrow($x))) { ... return_next(...); } The changes do not affect the spi_exec_query() interface in any way. Abhijit Menon-Sen
2005-07-10 17:19:43 +02:00
plan = SPI_prepare(query, 0, NULL);
Prepared queries for PLPerl, plus fixing a small plperl memory leak. Patch and docs from Dmitry Karasik, slightly editorialised.
2006-03-05 17:40:51 +01:00
if (plan == NULL)
elog(ERROR, "SPI_prepare() failed:%s",
SPI_result_code_string(SPI_result));
portal = SPI_cursor_open(NULL, plan, NULL, NULL, false);
SPI_freeplan(plan);
if (portal == NULL)
elog(ERROR, "SPI_cursor_open() failed:%s",
SPI_result_code_string(SPI_result));
Force strings passed to and from plperl to be in UTF8 encoding. String are converted to UTF8 on the way into perl and to the database encoding on the way back. This avoids a number of observed anomalies, and ensures Perl a consistent view of the world. Some minor code cleanups are also accomplished. Alex Hunsaker, reviewed by Andy Colson.
2011-02-06 23:29:26 +01:00
cursor = cstr2sv(portal->name);
The attached patch implements spi_query() and spi_fetchrow() functions for PL/Perl, to avoid loading the entire result set into memory as the existing spi_exec_query() function does. Here's how one might use the new functions: $x = spi_query("select ..."); while (defined ($y = spi_fetchrow($x))) { ... return_next(...); } The changes do not affect the spi_exec_query() interface in any way. Abhijit Menon-Sen
2005-07-10 17:19:43 +02:00
Use portal pinning in PL/Perl and PL/Python PL/pgSQL "pins" internally generated portals so that user code cannot close them by guessing their names. Add this functionality to PL/Perl and PL/Python as well, preventing users from manually closing cursors created by spi_query and plpy.cursor, respectively. (PL/Tcl does not currently offer any cursor functionality.)
2017-12-12 16:26:47 +01:00
PinPortal(portal);
Code review for spi_query/spi_fetchrow patch: handle errors sanely, avoid leaking memory. I would add a regression test for error handling except it seems eval{} can't be used in unprivileged plperl :-(
2005-10-18 19:13:14 +02:00
/* Commit the inner transaction, return to outer xact context */
The attached patch implements spi_query() and spi_fetchrow() functions for PL/Perl, to avoid loading the entire result set into memory as the existing spi_exec_query() function does. Here's how one might use the new functions: $x = spi_query("select ..."); while (defined ($y = spi_fetchrow($x))) { ... return_next(...); } The changes do not affect the spi_exec_query() interface in any way. Abhijit Menon-Sen
2005-07-10 17:19:43 +02:00
ReleaseCurrentSubTransaction();
MemoryContextSwitchTo(oldcontext);
CurrentResourceOwner = oldowner;
}
PG_CATCH();
{
ErrorData *edata;
Code review for spi_query/spi_fetchrow patch: handle errors sanely, avoid leaking memory. I would add a regression test for error handling except it seems eval{} can't be used in unprivileged plperl :-(
2005-10-18 19:13:14 +02:00
/* Save error info */
The attached patch implements spi_query() and spi_fetchrow() functions for PL/Perl, to avoid loading the entire result set into memory as the existing spi_exec_query() function does. Here's how one might use the new functions: $x = spi_query("select ..."); while (defined ($y = spi_fetchrow($x))) { ... return_next(...); } The changes do not affect the spi_exec_query() interface in any way. Abhijit Menon-Sen
2005-07-10 17:19:43 +02:00
MemoryContextSwitchTo(oldcontext);
edata = CopyErrorData();
FlushErrorState();
Code review for spi_query/spi_fetchrow patch: handle errors sanely, avoid leaking memory. I would add a regression test for error handling except it seems eval{} can't be used in unprivileged plperl :-(
2005-10-18 19:13:14 +02:00
/* Abort the inner transaction */
The attached patch implements spi_query() and spi_fetchrow() functions for PL/Perl, to avoid loading the entire result set into memory as the existing spi_exec_query() function does. Here's how one might use the new functions: $x = spi_query("select ..."); while (defined ($y = spi_fetchrow($x))) { ... return_next(...); } The changes do not affect the spi_exec_query() interface in any way. Abhijit Menon-Sen
2005-07-10 17:19:43 +02:00
RollbackAndReleaseCurrentSubTransaction();
MemoryContextSwitchTo(oldcontext);
CurrentResourceOwner = oldowner;
Code review for spi_query/spi_fetchrow patch: handle errors sanely, avoid leaking memory. I would add a regression test for error handling except it seems eval{} can't be used in unprivileged plperl :-(
2005-10-18 19:13:14 +02:00
/* Punt the error to Perl */
Fix plperl to handle non-ASCII error message texts correctly. We were passing error message texts to croak() verbatim, which turns out not to work if the text contains non-ASCII characters; Perl mangles their encoding, as reported in bug #13638 from Michal Leinweber. To fix, convert the text into a UTF8-encoded SV first. It's hard to test this without risking failures in different database encodings; but we can follow the lead of plpython, which is already assuming that no-break space (U+00A0) has an equivalent in all encodings we care about running the regression tests in (cf commit 2dfa15de5). Back-patch to 9.1. The code is quite different in 9.0, and anyway it seems too risky to put something like this into 9.0's final minor release. Alex Hunsaker, with suggestions from Tim Bunce and Tom Lane
2015-09-29 16:52:22 +02:00
croak_cstr(edata->message);
Code review for spi_query/spi_fetchrow patch: handle errors sanely, avoid leaking memory. I would add a regression test for error handling except it seems eval{} can't be used in unprivileged plperl :-(
2005-10-18 19:13:14 +02:00
/* Can't get here, but keep compiler quiet */
The attached patch implements spi_query() and spi_fetchrow() functions for PL/Perl, to avoid loading the entire result set into memory as the existing spi_exec_query() function does. Here's how one might use the new functions: $x = spi_query("select ..."); while (defined ($y = spi_fetchrow($x))) { ... return_next(...); } The changes do not affect the spi_exec_query() interface in any way. Abhijit Menon-Sen
2005-07-10 17:19:43 +02:00
return NULL;
}
PG_END_TRY();
return cursor;
}
SV *
plperl_spi_fetchrow(char *cursor)
{
Code review for spi_query/spi_fetchrow patch: handle errors sanely, avoid leaking memory. I would add a regression test for error handling except it seems eval{} can't be used in unprivileged plperl :-(
2005-10-18 19:13:14 +02:00
SV *row;
/*
* Execute the FETCH inside a sub-transaction, so we can cope with errors
* sanely
*/
MemoryContext oldcontext = CurrentMemoryContext;
ResourceOwner oldowner = CurrentResourceOwner;
The attached patch implements spi_query() and spi_fetchrow() functions for PL/Perl, to avoid loading the entire result set into memory as the existing spi_exec_query() function does. Here's how one might use the new functions: $x = spi_query("select ..."); while (defined ($y = spi_fetchrow($x))) { ... return_next(...); } The changes do not affect the spi_exec_query() interface in any way. Abhijit Menon-Sen
2005-07-10 17:19:43 +02:00
Add plperl.on_perl_init setting to provide for initializing the perl library on load. Also, handle END blocks in plperl. Database access is disallowed during both these operations, although it might be allowed in END blocks in future. Patch from Tim Bunce.
2010-01-30 02:46:57 +01:00
check_spi_usage_allowed();
Code review for spi_query/spi_fetchrow patch: handle errors sanely, avoid leaking memory. I would add a regression test for error handling except it seems eval{} can't be used in unprivileged plperl :-(
2005-10-18 19:13:14 +02:00
BeginInternalSubTransaction(NULL);
/* Want to run inside function's memory context */
MemoryContextSwitchTo(oldcontext);
The attached patch implements spi_query() and spi_fetchrow() functions for PL/Perl, to avoid loading the entire result set into memory as the existing spi_exec_query() function does. Here's how one might use the new functions: $x = spi_query("select ..."); while (defined ($y = spi_fetchrow($x))) { ... return_next(...); } The changes do not affect the spi_exec_query() interface in any way. Abhijit Menon-Sen
2005-07-10 17:19:43 +02:00
Code review for spi_query/spi_fetchrow patch: handle errors sanely, avoid leaking memory. I would add a regression test for error handling except it seems eval{} can't be used in unprivileged plperl :-(
2005-10-18 19:13:14 +02:00
PG_TRY();
The attached patch implements spi_query() and spi_fetchrow() functions for PL/Perl, to avoid loading the entire result set into memory as the existing spi_exec_query() function does. Here's how one might use the new functions: $x = spi_query("select ..."); while (defined ($y = spi_fetchrow($x))) { ... return_next(...); } The changes do not affect the spi_exec_query() interface in any way. Abhijit Menon-Sen
2005-07-10 17:19:43 +02:00
{
PL/Perl portability fix: avoid including XSUB.h in plperl.c. In Perl builds that define PERL_IMPLICIT_SYS, XSUB.h defines macros that replace a whole lot of basic libc functions with Perl functions. We can't tolerate that in plperl.c; it breaks at least PG_TRY and probably other stuff. The core idea of this patch is to include XSUB.h only in the .xs files where it's really needed, and to move any code broken by PERL_IMPLICIT_SYS out of the .xs files and into plperl.c. The reason this hasn't been a problem before is that our build techniques did not result in PERL_IMPLICIT_SYS appearing as a #define in PL/Perl, even on some platforms where Perl thinks it is defined. That's about to change in order to fix a nasty portability issue, so we need this work to make the code safe for that. Rather unaccountably, the Perl people chose XSUB.h as the place to provide the versions of the aTHX/aTHX_ macros that are needed by code that's not explicitly aware of the MULTIPLICITY API conventions. Hence, just removing XSUB.h from plperl.c fails miserably. But we can work around that by defining PERL_NO_GET_CONTEXT (which would make the relevant stanza of XSUB.h a no-op anyway). As explained in perlguts.pod, that means we need to add a "dTHX" macro call in every C function that calls a Perl API function. In most of them we just add this at the top; but since the macro fetches the current Perl interpreter pointer, more care is needed in functions that switch the active interpreter. Lack of the macro is easily recognized since it results in bleats about "my_perl" not being defined. (A nice side benefit of this is that it significantly reduces the number of fetches of the current interpreter pointer. On my machine, plperl.so gets more than 10% smaller, and there's probably some performance win too. We could reduce the number of fetches still more by decorating the code with pTHX_/aTHX_ macros to pass the interpreter pointer around, as explained by perlguts.pod; but that's a task for another day.) Formatting note: pgindent seems happy to treat "dTHX;" as a declaration so long as it's the first thing after the left brace, as we'd already observed with respect to the similar macro "dSP;". If you try to put it later in a set of declarations, pgindent puts ugly extra space around it. Having removed XSUB.h from plperl.c, we need only move the support functions for spi_return_next and util_elog (both of which use PG_TRY) out of the .xs files and into plperl.c. This seems sufficient to avoid the known problems caused by PERL_IMPLICIT_SYS, although we could move more code if additional issues emerge. This will need to be back-patched, but first let's see what the buildfarm makes of it. Patch by me, with some help from Ashutosh Sharma Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
2017-07-28 18:25:43 +02:00
dTHX;
Code review for spi_query/spi_fetchrow patch: handle errors sanely, avoid leaking memory. I would add a regression test for error handling except it seems eval{} can't be used in unprivileged plperl :-(
2005-10-18 19:13:14 +02:00
Portal p = SPI_cursor_find(cursor);
if (!p)
Prepared queries for PLPerl, plus fixing a small plperl memory leak. Patch and docs from Dmitry Karasik, slightly editorialised.
2006-03-05 17:40:51 +01:00
{
row = &PL_sv_undef;
}
Code review for spi_query/spi_fetchrow patch: handle errors sanely, avoid leaking memory. I would add a regression test for error handling except it seems eval{} can't be used in unprivileged plperl :-(
2005-10-18 19:13:14 +02:00
else
{
SPI_cursor_fetch(p, true, 1);
if (SPI_processed == 0)
{
Use portal pinning in PL/Perl and PL/Python PL/pgSQL "pins" internally generated portals so that user code cannot close them by guessing their names. Add this functionality to PL/Perl and PL/Python as well, preventing users from manually closing cursors created by spi_query and plpy.cursor, respectively. (PL/Tcl does not currently offer any cursor functionality.)
2017-12-12 16:26:47 +01:00
UnpinPortal(p);
Code review for spi_query/spi_fetchrow patch: handle errors sanely, avoid leaking memory. I would add a regression test for error handling except it seems eval{} can't be used in unprivileged plperl :-(
2005-10-18 19:13:14 +02:00
SPI_cursor_close(p);
Prepared queries for PLPerl, plus fixing a small plperl memory leak. Patch and docs from Dmitry Karasik, slightly editorialised.
2006-03-05 17:40:51 +01:00
row = &PL_sv_undef;
Code review for spi_query/spi_fetchrow patch: handle errors sanely, avoid leaking memory. I would add a regression test for error handling except it seems eval{} can't be used in unprivileged plperl :-(
2005-10-18 19:13:14 +02:00
}
else
{
row = plperl_hash_from_tuple(SPI_tuptable->vals[0],
Generated columns This is an SQL-standard feature that allows creating columns that are computed from expressions rather than assigned, similar to a view or materialized view but on a column basis. This implements one kind of generated column: stored (computed on write). Another kind, virtual (computed on read), is planned for the future, and some room is left for it. Reviewed-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Pavel Stehule <pavel.stehule@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/b151f851-4019-bdb1-699e-ebab07d2f40a@2ndquadrant.com
2019-03-30 08:13:09 +01:00
SPI_tuptable->tupdesc,
true);
Code review for spi_query/spi_fetchrow patch: handle errors sanely, avoid leaking memory. I would add a regression test for error handling except it seems eval{} can't be used in unprivileged plperl :-(
2005-10-18 19:13:14 +02:00
}
SPI_freetuptable(SPI_tuptable);
}
/* Commit the inner transaction, return to outer xact context */
ReleaseCurrentSubTransaction();
MemoryContextSwitchTo(oldcontext);
CurrentResourceOwner = oldowner;
The attached patch implements spi_query() and spi_fetchrow() functions for PL/Perl, to avoid loading the entire result set into memory as the existing spi_exec_query() function does. Here's how one might use the new functions: $x = spi_query("select ..."); while (defined ($y = spi_fetchrow($x))) { ... return_next(...); } The changes do not affect the spi_exec_query() interface in any way. Abhijit Menon-Sen
2005-07-10 17:19:43 +02:00
}
Code review for spi_query/spi_fetchrow patch: handle errors sanely, avoid leaking memory. I would add a regression test for error handling except it seems eval{} can't be used in unprivileged plperl :-(
2005-10-18 19:13:14 +02:00
PG_CATCH();
{
ErrorData *edata;
The attached patch implements spi_query() and spi_fetchrow() functions for PL/Perl, to avoid loading the entire result set into memory as the existing spi_exec_query() function does. Here's how one might use the new functions: $x = spi_query("select ..."); while (defined ($y = spi_fetchrow($x))) { ... return_next(...); } The changes do not affect the spi_exec_query() interface in any way. Abhijit Menon-Sen
2005-07-10 17:19:43 +02:00
Code review for spi_query/spi_fetchrow patch: handle errors sanely, avoid leaking memory. I would add a regression test for error handling except it seems eval{} can't be used in unprivileged plperl :-(
2005-10-18 19:13:14 +02:00
/* Save error info */
MemoryContextSwitchTo(oldcontext);
edata = CopyErrorData();
FlushErrorState();
/* Abort the inner transaction */
RollbackAndReleaseCurrentSubTransaction();
MemoryContextSwitchTo(oldcontext);
CurrentResourceOwner = oldowner;
/* Punt the error to Perl */
Fix plperl to handle non-ASCII error message texts correctly. We were passing error message texts to croak() verbatim, which turns out not to work if the text contains non-ASCII characters; Perl mangles their encoding, as reported in bug #13638 from Michal Leinweber. To fix, convert the text into a UTF8-encoded SV first. It's hard to test this without risking failures in different database encodings; but we can follow the lead of plpython, which is already assuming that no-break space (U+00A0) has an equivalent in all encodings we care about running the regression tests in (cf commit 2dfa15de5). Back-patch to 9.1. The code is quite different in 9.0, and anyway it seems too risky to put something like this into 9.0's final minor release. Alex Hunsaker, with suggestions from Tim Bunce and Tom Lane
2015-09-29 16:52:22 +02:00
croak_cstr(edata->message);
Code review for spi_query/spi_fetchrow patch: handle errors sanely, avoid leaking memory. I would add a regression test for error handling except it seems eval{} can't be used in unprivileged plperl :-(
2005-10-18 19:13:14 +02:00
/* Can't get here, but keep compiler quiet */
return NULL;
}
PG_END_TRY();
The attached patch implements spi_query() and spi_fetchrow() functions for PL/Perl, to avoid loading the entire result set into memory as the existing spi_exec_query() function does. Here's how one might use the new functions: $x = spi_query("select ..."); while (defined ($y = spi_fetchrow($x))) { ... return_next(...); } The changes do not affect the spi_exec_query() interface in any way. Abhijit Menon-Sen
2005-07-10 17:19:43 +02:00
return row;
}
Prepared queries for PLPerl, plus fixing a small plperl memory leak. Patch and docs from Dmitry Karasik, slightly editorialised.
2006-03-05 17:40:51 +01:00
void
plperl_spi_cursor_close(char *cursor)
{
Add plperl.on_perl_init setting to provide for initializing the perl library on load. Also, handle END blocks in plperl. Database access is disallowed during both these operations, although it might be allowed in END blocks in future. Patch from Tim Bunce.
2010-01-30 02:46:57 +01:00
Portal p;
check_spi_usage_allowed();
p = SPI_cursor_find(cursor);
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
Prepared queries for PLPerl, plus fixing a small plperl memory leak. Patch and docs from Dmitry Karasik, slightly editorialised.
2006-03-05 17:40:51 +01:00
if (p)
Use portal pinning in PL/Perl and PL/Python PL/pgSQL "pins" internally generated portals so that user code cannot close them by guessing their names. Add this functionality to PL/Perl and PL/Python as well, preventing users from manually closing cursors created by spi_query and plpy.cursor, respectively. (PL/Tcl does not currently offer any cursor functionality.)
2017-12-12 16:26:47 +01:00
{
UnpinPortal(p);
Prepared queries for PLPerl, plus fixing a small plperl memory leak. Patch and docs from Dmitry Karasik, slightly editorialised.
2006-03-05 17:40:51 +01:00
SPI_cursor_close(p);
Use portal pinning in PL/Perl and PL/Python PL/pgSQL "pins" internally generated portals so that user code cannot close them by guessing their names. Add this functionality to PL/Perl and PL/Python as well, preventing users from manually closing cursors created by spi_query and plpy.cursor, respectively. (PL/Tcl does not currently offer any cursor functionality.)
2017-12-12 16:26:47 +01:00
}
Prepared queries for PLPerl, plus fixing a small plperl memory leak. Patch and docs from Dmitry Karasik, slightly editorialised.
2006-03-05 17:40:51 +01:00
}
SV *
plperl_spi_prepare(char *query, int argc, SV **argv)
{
Eliminate memory leaks in plperl's spi_prepare() function. Careless use of TopMemoryContext for I/O function data meant that repeated use of spi_prepare and spi_freeplan would leak memory at the session level, as per report from Christian Schröder. In addition, spi_prepare leaked a lot of transient data within the current plperl function's SPI Proc context, which would be a problem for repeated use of spi_prepare within a single plperl function call; and it wasn't terribly careful about releasing permanent allocations in event of an error, either. In passing, clean up some copy-and-pasteos in query-lookup error messages. Alex Hunsaker and Tom Lane
2013-03-02 03:33:34 +01:00
volatile SPIPlanPtr plan = NULL;
volatile MemoryContext plan_cxt = NULL;
plperl_query_desc *volatile qdesc = NULL;
plperl_query_entry *volatile hash_entry = NULL;
Prepared queries for PLPerl, plus fixing a small plperl memory leak. Patch and docs from Dmitry Karasik, slightly editorialised.
2006-03-05 17:40:51 +01:00
MemoryContext oldcontext = CurrentMemoryContext;
ResourceOwner oldowner = CurrentResourceOwner;
Eliminate memory leaks in plperl's spi_prepare() function. Careless use of TopMemoryContext for I/O function data meant that repeated use of spi_prepare and spi_freeplan would leak memory at the session level, as per report from Christian Schröder. In addition, spi_prepare leaked a lot of transient data within the current plperl function's SPI Proc context, which would be a problem for repeated use of spi_prepare within a single plperl function call; and it wasn't terribly careful about releasing permanent allocations in event of an error, either. In passing, clean up some copy-and-pasteos in query-lookup error messages. Alex Hunsaker and Tom Lane
2013-03-02 03:33:34 +01:00
MemoryContext work_cxt;
bool found;
int i;
Prepared queries for PLPerl, plus fixing a small plperl memory leak. Patch and docs from Dmitry Karasik, slightly editorialised.
2006-03-05 17:40:51 +01:00
Add plperl.on_perl_init setting to provide for initializing the perl library on load. Also, handle END blocks in plperl. Database access is disallowed during both these operations, although it might be allowed in END blocks in future. Patch from Tim Bunce.
2010-01-30 02:46:57 +01:00
check_spi_usage_allowed();
Prepared queries for PLPerl, plus fixing a small plperl memory leak. Patch and docs from Dmitry Karasik, slightly editorialised.
2006-03-05 17:40:51 +01:00
BeginInternalSubTransaction(NULL);
MemoryContextSwitchTo(oldcontext);
PG_TRY();
{
Eliminate memory leaks in plperl's spi_prepare() function. Careless use of TopMemoryContext for I/O function data meant that repeated use of spi_prepare and spi_freeplan would leak memory at the session level, as per report from Christian Schröder. In addition, spi_prepare leaked a lot of transient data within the current plperl function's SPI Proc context, which would be a problem for repeated use of spi_prepare within a single plperl function call; and it wasn't terribly careful about releasing permanent allocations in event of an error, either. In passing, clean up some copy-and-pasteos in query-lookup error messages. Alex Hunsaker and Tom Lane
2013-03-02 03:33:34 +01:00
CHECK_FOR_INTERRUPTS();
/************************************************************
* Allocate the new querydesc structure
*
* The qdesc struct, as well as all its subsidiary data, lives in its
* plan_cxt. But note that the SPIPlan does not.
************************************************************/
plan_cxt = AllocSetContextCreate(TopMemoryContext,
"PL/Perl spi_prepare query",
Add macros to make AllocSetContextCreate() calls simpler and safer. I found that half a dozen (nearly 5%) of our AllocSetContextCreate calls had typos in the context-sizing parameters. While none of these led to especially significant problems, they did create minor inefficiencies, and it's now clear that expecting people to copy-and-paste those calls accurately is not a great idea. Let's reduce the risk of future errors by introducing single macros that encapsulate the common use-cases. Three such macros are enough to cover all but two special-purpose contexts; those two calls can be left as-is, I think. While this patch doesn't in itself improve matters for third-party extensions, it doesn't break anything for them either, and they can gradually adopt the simplified notation over time. In passing, change TopMemoryContext to use the default allocation parameters. Formerly it could only be extended 8K at a time. That was probably reasonable when this code was written; but nowadays we create many more contexts than we did then, so that it's not unusual to have a couple hundred K in TopMemoryContext, even without considering various dubious code that sticks other things there. There seems no good reason not to let it use growing blocks like most other contexts. Back-patch to 9.6, mostly because that's still close enough to HEAD that it's easy to do so, and keeping the branches in sync can be expected to avoid some future back-patching pain. The bugs fixed by these changes don't seem to be significant enough to justify fixing them further back. Discussion: <21072.1472321324@sss.pgh.pa.us>
2016-08-27 23:50:38 +02:00
ALLOCSET_SMALL_SIZES);
Eliminate memory leaks in plperl's spi_prepare() function. Careless use of TopMemoryContext for I/O function data meant that repeated use of spi_prepare and spi_freeplan would leak memory at the session level, as per report from Christian Schröder. In addition, spi_prepare leaked a lot of transient data within the current plperl function's SPI Proc context, which would be a problem for repeated use of spi_prepare within a single plperl function call; and it wasn't terribly careful about releasing permanent allocations in event of an error, either. In passing, clean up some copy-and-pasteos in query-lookup error messages. Alex Hunsaker and Tom Lane
2013-03-02 03:33:34 +01:00
MemoryContextSwitchTo(plan_cxt);
qdesc = (plperl_query_desc *) palloc0(sizeof(plperl_query_desc));
snprintf(qdesc->qname, sizeof(qdesc->qname), "%p", qdesc);
qdesc->plan_cxt = plan_cxt;
qdesc->nargs = argc;
qdesc->argtypes = (Oid *) palloc(argc * sizeof(Oid));
qdesc->arginfuncs = (FmgrInfo *) palloc(argc * sizeof(FmgrInfo));
qdesc->argtypioparams = (Oid *) palloc(argc * sizeof(Oid));
MemoryContextSwitchTo(oldcontext);
/************************************************************
* Do the following work in a short-lived context so that we don't
* leak a lot of memory in the PL/Perl function's SPI Proc context.
************************************************************/
work_cxt = AllocSetContextCreate(CurrentMemoryContext,
"PL/Perl spi_prepare workspace",
Add macros to make AllocSetContextCreate() calls simpler and safer. I found that half a dozen (nearly 5%) of our AllocSetContextCreate calls had typos in the context-sizing parameters. While none of these led to especially significant problems, they did create minor inefficiencies, and it's now clear that expecting people to copy-and-paste those calls accurately is not a great idea. Let's reduce the risk of future errors by introducing single macros that encapsulate the common use-cases. Three such macros are enough to cover all but two special-purpose contexts; those two calls can be left as-is, I think. While this patch doesn't in itself improve matters for third-party extensions, it doesn't break anything for them either, and they can gradually adopt the simplified notation over time. In passing, change TopMemoryContext to use the default allocation parameters. Formerly it could only be extended 8K at a time. That was probably reasonable when this code was written; but nowadays we create many more contexts than we did then, so that it's not unusual to have a couple hundred K in TopMemoryContext, even without considering various dubious code that sticks other things there. There seems no good reason not to let it use growing blocks like most other contexts. Back-patch to 9.6, mostly because that's still close enough to HEAD that it's easy to do so, and keeping the branches in sync can be expected to avoid some future back-patching pain. The bugs fixed by these changes don't seem to be significant enough to justify fixing them further back. Discussion: <21072.1472321324@sss.pgh.pa.us>
2016-08-27 23:50:38 +02:00
ALLOCSET_DEFAULT_SIZES);
Eliminate memory leaks in plperl's spi_prepare() function. Careless use of TopMemoryContext for I/O function data meant that repeated use of spi_prepare and spi_freeplan would leak memory at the session level, as per report from Christian Schröder. In addition, spi_prepare leaked a lot of transient data within the current plperl function's SPI Proc context, which would be a problem for repeated use of spi_prepare within a single plperl function call; and it wasn't terribly careful about releasing permanent allocations in event of an error, either. In passing, clean up some copy-and-pasteos in query-lookup error messages. Alex Hunsaker and Tom Lane
2013-03-02 03:33:34 +01:00
MemoryContextSwitchTo(work_cxt);
Prepared queries for PLPerl, plus fixing a small plperl memory leak. Patch and docs from Dmitry Karasik, slightly editorialised.
2006-03-05 17:40:51 +01:00
/************************************************************
Combine cmin and cmax fields of HeapTupleHeaders into a single field, by keeping private state in each backend that has inserted and deleted the same tuple during its current top-level transaction. This is sufficient since there is no need to be able to determine the cmin/cmax from any other transaction. This gets us back down to 23-byte headers, removing a penalty paid in 8.0 to support subtransactions. Patch by Heikki Linnakangas, with minor revisions by moi, following a design hashed out awhile back on the pghackers list.
2007-02-09 04:35:35 +01:00
* Resolve argument type names and then look them up by oid
* in the system cache, and remember the required information
* for input conversion.
Prepared queries for PLPerl, plus fixing a small plperl memory leak. Patch and docs from Dmitry Karasik, slightly editorialised.
2006-03-05 17:40:51 +01:00
************************************************************/
for (i = 0; i < argc; i++)
{
Allow args to spi_prepare to be standard type aliaes as well as those known in pg_type. Fixes bug #2917. Add some regression tests for these cases.
2007-01-27 02:55:57 +01:00
Oid typId,
typInput,
typIOParam;
int32 typmod;
pgindent run on plperl.c
2011-02-17 20:40:13 +01:00
char *typstr;
Allow args to spi_prepare to be standard type aliaes as well as those known in pg_type. Fixes bug #2917. Add some regression tests for these cases.
2007-01-27 02:55:57 +01:00
Force strings passed to and from plperl to be in UTF8 encoding. String are converted to UTF8 on the way into perl and to the database encoding on the way back. This avoids a number of observed anomalies, and ensures Perl a consistent view of the world. Some minor code cleanups are also accomplished. Alex Hunsaker, reviewed by Andy Colson.
2011-02-06 23:29:26 +01:00
typstr = sv2cstr(argv[i]);
Convert the reg* input functions to report (most) errors softly. This is not really complete, but it catches most cases of practical interest. The main omissions are: * regtype, regprocedure, and regoperator parse type names by calling the main grammar, so any grammar-detected syntax error will still be a hard error. Also, if one includes a type modifier in such a type specification, errors detected by the typmodin function will be hard errors. * Lookup errors are handled just by passing missing_ok = true to the relevant catalog lookup function. Because we've used quite a restrictive definition of "missing_ok", this means that edge cases such as "the named schema exists, but you lack USAGE permission on it" are still hard errors. It would make sense to me to replace most/all missing_ok parameters with an escontext parameter and then allow these additional lookup failure cases to be trapped too. But that's a job for some other day. Discussion: https://postgr.es/m/3342239.1671988406@sss.pgh.pa.us
2022-12-27 18:26:01 +01:00
(void) parseTypeString(typstr, &typId, &typmod, NULL);
Force strings passed to and from plperl to be in UTF8 encoding. String are converted to UTF8 on the way into perl and to the database encoding on the way back. This avoids a number of observed anomalies, and ensures Perl a consistent view of the world. Some minor code cleanups are also accomplished. Alex Hunsaker, reviewed by Andy Colson.
2011-02-06 23:29:26 +01:00
pfree(typstr);
Allow args to spi_prepare to be standard type aliaes as well as those known in pg_type. Fixes bug #2917. Add some regression tests for these cases.
2007-01-27 02:55:57 +01:00
getTypeInputInfo(typId, &typInput, &typIOParam);
qdesc->argtypes[i] = typId;
Eliminate memory leaks in plperl's spi_prepare() function. Careless use of TopMemoryContext for I/O function data meant that repeated use of spi_prepare and spi_freeplan would leak memory at the session level, as per report from Christian Schröder. In addition, spi_prepare leaked a lot of transient data within the current plperl function's SPI Proc context, which would be a problem for repeated use of spi_prepare within a single plperl function call; and it wasn't terribly careful about releasing permanent allocations in event of an error, either. In passing, clean up some copy-and-pasteos in query-lookup error messages. Alex Hunsaker and Tom Lane
2013-03-02 03:33:34 +01:00
fmgr_info_cxt(typInput, &(qdesc->arginfuncs[i]), plan_cxt);
Allow args to spi_prepare to be standard type aliaes as well as those known in pg_type. Fixes bug #2917. Add some regression tests for these cases.
2007-01-27 02:55:57 +01:00
qdesc->argtypioparams[i] = typIOParam;
Prepared queries for PLPerl, plus fixing a small plperl memory leak. Patch and docs from Dmitry Karasik, slightly editorialised.
2006-03-05 17:40:51 +01:00
}
Add checks for valid encoding of query strings passed to SPI by plperl.
2010-03-09 03:48:33 +01:00
/* Make sure the query is validly encoded */
pg_verifymbstr(query, strlen(query), false);
Prepared queries for PLPerl, plus fixing a small plperl memory leak. Patch and docs from Dmitry Karasik, slightly editorialised.
2006-03-05 17:40:51 +01:00
/************************************************************
* Prepare the plan and check for errors
************************************************************/
plan = SPI_prepare(query, argc, qdesc->argtypes);
if (plan == NULL)
elog(ERROR, "SPI_prepare() failed:%s",
SPI_result_code_string(SPI_result));
/************************************************************
* Save the plan into permanent memory (right now it's in the
* SPI procCxt, which will go away at function end).
************************************************************/
Redesign the plancache mechanism for more flexibility and efficiency. Rewrite plancache.c so that a "cached plan" (which is rather a misnomer at this point) can support generation of custom, parameter-value-dependent plans, and can make an intelligent choice between using custom plans and the traditional generic-plan approach. The specific choice algorithm implemented here can probably be improved in future, but this commit is all about getting the mechanism in place, not the policy. In addition, restructure the API to greatly reduce the amount of extraneous data copying needed. The main compromise needed to make that possible was to split the initial creation of a CachedPlanSource into two steps. It's worth noting in particular that SPI_saveplan is now deprecated in favor of SPI_keepplan, which accomplishes the same end result with zero data copying, and no need to then spend even more cycles throwing away the original SPIPlan. The risk of long-term memory leaks while manipulating SPIPlans has also been greatly reduced. Most of this improvement is based on use of the recently-added MemoryContextSetParent primitive.
2011-09-16 06:42:53 +02:00
if (SPI_keepplan(plan))
elog(ERROR, "SPI_keepplan() failed");
qdesc->plan = plan;
Prepared queries for PLPerl, plus fixing a small plperl memory leak. Patch and docs from Dmitry Karasik, slightly editorialised.
2006-03-05 17:40:51 +01:00
Eliminate memory leaks in plperl's spi_prepare() function. Careless use of TopMemoryContext for I/O function data meant that repeated use of spi_prepare and spi_freeplan would leak memory at the session level, as per report from Christian Schröder. In addition, spi_prepare leaked a lot of transient data within the current plperl function's SPI Proc context, which would be a problem for repeated use of spi_prepare within a single plperl function call; and it wasn't terribly careful about releasing permanent allocations in event of an error, either. In passing, clean up some copy-and-pasteos in query-lookup error messages. Alex Hunsaker and Tom Lane
2013-03-02 03:33:34 +01:00
/************************************************************
* Insert a hashtable entry for the plan.
************************************************************/
hash_entry = hash_search(plperl_active_interp->query_hash,
qdesc->qname,
HASH_ENTER, &found);
hash_entry->query_data = qdesc;
/* Get rid of workspace */
MemoryContextDelete(work_cxt);
Prepared queries for PLPerl, plus fixing a small plperl memory leak. Patch and docs from Dmitry Karasik, slightly editorialised.
2006-03-05 17:40:51 +01:00
/* Commit the inner transaction, return to outer xact context */
ReleaseCurrentSubTransaction();
MemoryContextSwitchTo(oldcontext);
CurrentResourceOwner = oldowner;
}
PG_CATCH();
{
ErrorData *edata;
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
Prepared queries for PLPerl, plus fixing a small plperl memory leak. Patch and docs from Dmitry Karasik, slightly editorialised.
2006-03-05 17:40:51 +01:00
/* Save error info */
MemoryContextSwitchTo(oldcontext);
edata = CopyErrorData();
FlushErrorState();
Eliminate memory leaks in plperl's spi_prepare() function. Careless use of TopMemoryContext for I/O function data meant that repeated use of spi_prepare and spi_freeplan would leak memory at the session level, as per report from Christian Schröder. In addition, spi_prepare leaked a lot of transient data within the current plperl function's SPI Proc context, which would be a problem for repeated use of spi_prepare within a single plperl function call; and it wasn't terribly careful about releasing permanent allocations in event of an error, either. In passing, clean up some copy-and-pasteos in query-lookup error messages. Alex Hunsaker and Tom Lane
2013-03-02 03:33:34 +01:00
/* Drop anything we managed to allocate */
if (hash_entry)
hash_search(plperl_active_interp->query_hash,
qdesc->qname,
HASH_REMOVE, NULL);
if (plan_cxt)
MemoryContextDelete(plan_cxt);
if (plan)
SPI_freeplan(plan);
Prepared queries for PLPerl, plus fixing a small plperl memory leak. Patch and docs from Dmitry Karasik, slightly editorialised.
2006-03-05 17:40:51 +01:00
/* Abort the inner transaction */
RollbackAndReleaseCurrentSubTransaction();
MemoryContextSwitchTo(oldcontext);
CurrentResourceOwner = oldowner;
/* Punt the error to Perl */
Fix plperl to handle non-ASCII error message texts correctly. We were passing error message texts to croak() verbatim, which turns out not to work if the text contains non-ASCII characters; Perl mangles their encoding, as reported in bug #13638 from Michal Leinweber. To fix, convert the text into a UTF8-encoded SV first. It's hard to test this without risking failures in different database encodings; but we can follow the lead of plpython, which is already assuming that no-break space (U+00A0) has an equivalent in all encodings we care about running the regression tests in (cf commit 2dfa15de5). Back-patch to 9.1. The code is quite different in 9.0, and anyway it seems too risky to put something like this into 9.0's final minor release. Alex Hunsaker, with suggestions from Tim Bunce and Tom Lane
2015-09-29 16:52:22 +02:00
croak_cstr(edata->message);
Prepared queries for PLPerl, plus fixing a small plperl memory leak. Patch and docs from Dmitry Karasik, slightly editorialised.
2006-03-05 17:40:51 +01:00
/* Can't get here, but keep compiler quiet */
return NULL;
}
PG_END_TRY();
/************************************************************
Eliminate memory leaks in plperl's spi_prepare() function. Careless use of TopMemoryContext for I/O function data meant that repeated use of spi_prepare and spi_freeplan would leak memory at the session level, as per report from Christian Schröder. In addition, spi_prepare leaked a lot of transient data within the current plperl function's SPI Proc context, which would be a problem for repeated use of spi_prepare within a single plperl function call; and it wasn't terribly careful about releasing permanent allocations in event of an error, either. In passing, clean up some copy-and-pasteos in query-lookup error messages. Alex Hunsaker and Tom Lane
2013-03-02 03:33:34 +01:00
* Return the query's hash key to the caller.
Prepared queries for PLPerl, plus fixing a small plperl memory leak. Patch and docs from Dmitry Karasik, slightly editorialised.
2006-03-05 17:40:51 +01:00
************************************************************/
Force strings passed to and from plperl to be in UTF8 encoding. String are converted to UTF8 on the way into perl and to the database encoding on the way back. This avoids a number of observed anomalies, and ensures Perl a consistent view of the world. Some minor code cleanups are also accomplished. Alex Hunsaker, reviewed by Andy Colson.
2011-02-06 23:29:26 +01:00
return cstr2sv(qdesc->qname);
Prepared queries for PLPerl, plus fixing a small plperl memory leak. Patch and docs from Dmitry Karasik, slightly editorialised.
2006-03-05 17:40:51 +01:00
}
HV *
plperl_spi_exec_prepared(char *query, HV *attr, int argc, SV **argv)
{
HV *ret_hv;
SV **sv;
int i,
limit,
spi_rv;
char *nulls;
Datum *argvalues;
plperl_query_desc *qdesc;
Force plperl and plperlu to run in separate interpreters. Create an error on an attempt to create the second interpreter if this is not supported by the perl installation. Per recent -hackers discussion.
2006-11-13 18:13:57 +01:00
plperl_query_entry *hash_entry;
Prepared queries for PLPerl, plus fixing a small plperl memory leak. Patch and docs from Dmitry Karasik, slightly editorialised.
2006-03-05 17:40:51 +01:00
/*
* Execute the query inside a sub-transaction, so we can cope with errors
* sanely
*/
MemoryContext oldcontext = CurrentMemoryContext;
ResourceOwner oldowner = CurrentResourceOwner;
Add plperl.on_perl_init setting to provide for initializing the perl library on load. Also, handle END blocks in plperl. Database access is disallowed during both these operations, although it might be allowed in END blocks in future. Patch from Tim Bunce.
2010-01-30 02:46:57 +01:00
check_spi_usage_allowed();
Prepared queries for PLPerl, plus fixing a small plperl memory leak. Patch and docs from Dmitry Karasik, slightly editorialised.
2006-03-05 17:40:51 +01:00
BeginInternalSubTransaction(NULL);
/* Want to run inside function's memory context */
MemoryContextSwitchTo(oldcontext);
PG_TRY();
{
PL/Perl portability fix: avoid including XSUB.h in plperl.c. In Perl builds that define PERL_IMPLICIT_SYS, XSUB.h defines macros that replace a whole lot of basic libc functions with Perl functions. We can't tolerate that in plperl.c; it breaks at least PG_TRY and probably other stuff. The core idea of this patch is to include XSUB.h only in the .xs files where it's really needed, and to move any code broken by PERL_IMPLICIT_SYS out of the .xs files and into plperl.c. The reason this hasn't been a problem before is that our build techniques did not result in PERL_IMPLICIT_SYS appearing as a #define in PL/Perl, even on some platforms where Perl thinks it is defined. That's about to change in order to fix a nasty portability issue, so we need this work to make the code safe for that. Rather unaccountably, the Perl people chose XSUB.h as the place to provide the versions of the aTHX/aTHX_ macros that are needed by code that's not explicitly aware of the MULTIPLICITY API conventions. Hence, just removing XSUB.h from plperl.c fails miserably. But we can work around that by defining PERL_NO_GET_CONTEXT (which would make the relevant stanza of XSUB.h a no-op anyway). As explained in perlguts.pod, that means we need to add a "dTHX" macro call in every C function that calls a Perl API function. In most of them we just add this at the top; but since the macro fetches the current Perl interpreter pointer, more care is needed in functions that switch the active interpreter. Lack of the macro is easily recognized since it results in bleats about "my_perl" not being defined. (A nice side benefit of this is that it significantly reduces the number of fetches of the current interpreter pointer. On my machine, plperl.so gets more than 10% smaller, and there's probably some performance win too. We could reduce the number of fetches still more by decorating the code with pTHX_/aTHX_ macros to pass the interpreter pointer around, as explained by perlguts.pod; but that's a task for another day.) Formatting note: pgindent seems happy to treat "dTHX;" as a declaration so long as it's the first thing after the left brace, as we'd already observed with respect to the similar macro "dSP;". If you try to put it later in a set of declarations, pgindent puts ugly extra space around it. Having removed XSUB.h from plperl.c, we need only move the support functions for spi_return_next and util_elog (both of which use PG_TRY) out of the .xs files and into plperl.c. This seems sufficient to avoid the known problems caused by PERL_IMPLICIT_SYS, although we could move more code if additional issues emerge. This will need to be back-patched, but first let's see what the buildfarm makes of it. Patch by me, with some help from Ashutosh Sharma Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
2017-07-28 18:25:43 +02:00
dTHX;
Prepared queries for PLPerl, plus fixing a small plperl memory leak. Patch and docs from Dmitry Karasik, slightly editorialised.
2006-03-05 17:40:51 +01:00
/************************************************************
* Fetch the saved plan descriptor, see if it's o.k.
************************************************************/
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
hash_entry = hash_search(plperl_active_interp->query_hash, query,
Force plperl and plperlu to run in separate interpreters. Create an error on an attempt to create the second interpreter if this is not supported by the perl installation. Per recent -hackers discussion.
2006-11-13 18:13:57 +01:00
HASH_FIND, NULL);
if (hash_entry == NULL)
Prepared queries for PLPerl, plus fixing a small plperl memory leak. Patch and docs from Dmitry Karasik, slightly editorialised.
2006-03-05 17:40:51 +01:00
elog(ERROR, "spi_exec_prepared: Invalid prepared query passed");
Force plperl and plperlu to run in separate interpreters. Create an error on an attempt to create the second interpreter if this is not supported by the perl installation. Per recent -hackers discussion.
2006-11-13 18:13:57 +01:00
qdesc = hash_entry->query_data;
Prepared queries for PLPerl, plus fixing a small plperl memory leak. Patch and docs from Dmitry Karasik, slightly editorialised.
2006-03-05 17:40:51 +01:00
if (qdesc == NULL)
Eliminate memory leaks in plperl's spi_prepare() function. Careless use of TopMemoryContext for I/O function data meant that repeated use of spi_prepare and spi_freeplan would leak memory at the session level, as per report from Christian Schröder. In addition, spi_prepare leaked a lot of transient data within the current plperl function's SPI Proc context, which would be a problem for repeated use of spi_prepare within a single plperl function call; and it wasn't terribly careful about releasing permanent allocations in event of an error, either. In passing, clean up some copy-and-pasteos in query-lookup error messages. Alex Hunsaker and Tom Lane
2013-03-02 03:33:34 +01:00
elog(ERROR, "spi_exec_prepared: plperl query_hash value vanished");
Prepared queries for PLPerl, plus fixing a small plperl memory leak. Patch and docs from Dmitry Karasik, slightly editorialised.
2006-03-05 17:40:51 +01:00
if (qdesc->nargs != argc)
elog(ERROR, "spi_exec_prepared: expected %d argument(s), %d passed",
qdesc->nargs, argc);
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
Prepared queries for PLPerl, plus fixing a small plperl memory leak. Patch and docs from Dmitry Karasik, slightly editorialised.
2006-03-05 17:40:51 +01:00
/************************************************************
* Parse eventual attributes
************************************************************/
limit = 0;
if (attr != NULL)
{
Adjust plperl to ensure that all strings and hash keys passed to Perl are marked as UTF8 when the database encoding is UTF8. This should avoid inconsistencies like that exhibited in bug #2683 from Vitali Stupin.
2006-10-15 20:56:39 +02:00
sv = hv_fetch_string(attr, "limit");
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
if (sv && *sv && SvIOK(*sv))
Prepared queries for PLPerl, plus fixing a small plperl memory leak. Patch and docs from Dmitry Karasik, slightly editorialised.
2006-03-05 17:40:51 +01:00
limit = SvIV(*sv);
}
/************************************************************
* Set up arguments
************************************************************/
Modify all callers of datatype input and receive functions so that if these functions are not strict, they will be called (passing a NULL first parameter) during any attempt to input a NULL value of their datatype. Currently, all our input functions are strict and so this commit does not change any behavior. However, this will make it possible to build domain input functions that centralize checking of domain constraints, thereby closing numerous holes in our domain support, as per previous discussion. While at it, I took the opportunity to introduce convenience functions InputFunctionCall, OutputFunctionCall, etc to use in code that calls I/O functions. This eliminates a lot of grotty-looking casts, but the main motivation is to make it easier to grep for these places if we ever need to touch them again.
2006-04-04 21:35:37 +02:00
if (argc > 0)
Prepared queries for PLPerl, plus fixing a small plperl memory leak. Patch and docs from Dmitry Karasik, slightly editorialised.
2006-03-05 17:40:51 +01:00
{
Modify all callers of datatype input and receive functions so that if these functions are not strict, they will be called (passing a NULL first parameter) during any attempt to input a NULL value of their datatype. Currently, all our input functions are strict and so this commit does not change any behavior. However, this will make it possible to build domain input functions that centralize checking of domain constraints, thereby closing numerous holes in our domain support, as per previous discussion. While at it, I took the opportunity to introduce convenience functions InputFunctionCall, OutputFunctionCall, etc to use in code that calls I/O functions. This eliminates a lot of grotty-looking casts, but the main motivation is to make it easier to grep for these places if we ever need to touch them again.
2006-04-04 21:35:37 +02:00
nulls = (char *) palloc(argc);
Prepared queries for PLPerl, plus fixing a small plperl memory leak. Patch and docs from Dmitry Karasik, slightly editorialised.
2006-03-05 17:40:51 +01:00
argvalues = (Datum *) palloc(argc * sizeof(Datum));
}
else
{
nulls = NULL;
argvalues = NULL;
}
Modify all callers of datatype input and receive functions so that if these functions are not strict, they will be called (passing a NULL first parameter) during any attempt to input a NULL value of their datatype. Currently, all our input functions are strict and so this commit does not change any behavior. However, this will make it possible to build domain input functions that centralize checking of domain constraints, thereby closing numerous holes in our domain support, as per previous discussion. While at it, I took the opportunity to introduce convenience functions InputFunctionCall, OutputFunctionCall, etc to use in code that calls I/O functions. This eliminates a lot of grotty-looking casts, but the main motivation is to make it easier to grep for these places if we ever need to touch them again.
2006-04-04 21:35:37 +02:00
for (i = 0; i < argc; i++)
Prepared queries for PLPerl, plus fixing a small plperl memory leak. Patch and docs from Dmitry Karasik, slightly editorialised.
2006-03-05 17:40:51 +01:00
{
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
bool isnull;
argvalues[i] = plperl_sv_to_datum(argv[i],
qdesc->argtypes[i],
Fix up Perl-to-Postgres datatype conversions in pl/perl. This patch restores the pre-9.1 behavior that pl/perl functions returning VOID ignore the result value of their last Perl statement. 9.1.0 unintentionally threw an error if the last statement returned a reference, as reported by Amit Khandekar. Also, make sure it works to return a string value for a composite type, so long as the string meets the type's input format. We already allowed the equivalent behavior for arrays, so it seems inconsistent to not allow it for composites. In addition, ensure we throw errors for attempts to return arrays or hashes when the function's declared result type is not an array or composite type, respectively. Pre-9.1 versions rather uselessly returned strings like ARRAY(0x221a9a0) or HASH(0x221aa90), while 9.1.0 threw an error for the hash case and returned a garbage value for the array case. Also, clean up assorted grotty coding in Perl array conversion, including use of a session-lifespan memory context to accumulate the array value (resulting in session-lifespan memory leak on error), failure to apply the declared typmod if any, and failure to detect some cases of non-rectangular multi-dimensional arrays. Alex Hunsaker and Tom Lane
2011-10-14 00:02:43 +02:00
-1,
NULL,
&qdesc->arginfuncs[i],
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
qdesc->argtypioparams[i],
Fix up Perl-to-Postgres datatype conversions in pl/perl. This patch restores the pre-9.1 behavior that pl/perl functions returning VOID ignore the result value of their last Perl statement. 9.1.0 unintentionally threw an error if the last statement returned a reference, as reported by Amit Khandekar. Also, make sure it works to return a string value for a composite type, so long as the string meets the type's input format. We already allowed the equivalent behavior for arrays, so it seems inconsistent to not allow it for composites. In addition, ensure we throw errors for attempts to return arrays or hashes when the function's declared result type is not an array or composite type, respectively. Pre-9.1 versions rather uselessly returned strings like ARRAY(0x221a9a0) or HASH(0x221aa90), while 9.1.0 threw an error for the hash case and returned a garbage value for the array case. Also, clean up assorted grotty coding in Perl array conversion, including use of a session-lifespan memory context to accumulate the array value (resulting in session-lifespan memory leak on error), failure to apply the declared typmod if any, and failure to detect some cases of non-rectangular multi-dimensional arrays. Alex Hunsaker and Tom Lane
2011-10-14 00:02:43 +02:00
&isnull);
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
nulls[i] = isnull ? 'n' : ' ';
Prepared queries for PLPerl, plus fixing a small plperl memory leak. Patch and docs from Dmitry Karasik, slightly editorialised.
2006-03-05 17:40:51 +01:00
}
/************************************************************
* go
************************************************************/
spi_rv = SPI_execute_plan(qdesc->plan, argvalues, nulls,
current_call_data->prodesc->fn_readonly, limit);
ret_hv = plperl_spi_execute_fetch_result(SPI_tuptable, SPI_processed,
spi_rv);
if (argc > 0)
{
pfree(argvalues);
pfree(nulls);
}
/* Commit the inner transaction, return to outer xact context */
ReleaseCurrentSubTransaction();
MemoryContextSwitchTo(oldcontext);
CurrentResourceOwner = oldowner;
}
PG_CATCH();
{
ErrorData *edata;
/* Save error info */
MemoryContextSwitchTo(oldcontext);
edata = CopyErrorData();
FlushErrorState();
/* Abort the inner transaction */
RollbackAndReleaseCurrentSubTransaction();
MemoryContextSwitchTo(oldcontext);
CurrentResourceOwner = oldowner;
/* Punt the error to Perl */
Fix plperl to handle non-ASCII error message texts correctly. We were passing error message texts to croak() verbatim, which turns out not to work if the text contains non-ASCII characters; Perl mangles their encoding, as reported in bug #13638 from Michal Leinweber. To fix, convert the text into a UTF8-encoded SV first. It's hard to test this without risking failures in different database encodings; but we can follow the lead of plpython, which is already assuming that no-break space (U+00A0) has an equivalent in all encodings we care about running the regression tests in (cf commit 2dfa15de5). Back-patch to 9.1. The code is quite different in 9.0, and anyway it seems too risky to put something like this into 9.0's final minor release. Alex Hunsaker, with suggestions from Tim Bunce and Tom Lane
2015-09-29 16:52:22 +02:00
croak_cstr(edata->message);
Prepared queries for PLPerl, plus fixing a small plperl memory leak. Patch and docs from Dmitry Karasik, slightly editorialised.
2006-03-05 17:40:51 +01:00
/* Can't get here, but keep compiler quiet */
return NULL;
}
PG_END_TRY();
return ret_hv;
}
SV *
plperl_spi_query_prepared(char *query, int argc, SV **argv)
{
int i;
char *nulls;
Datum *argvalues;
plperl_query_desc *qdesc;
Force plperl and plperlu to run in separate interpreters. Create an error on an attempt to create the second interpreter if this is not supported by the perl installation. Per recent -hackers discussion.
2006-11-13 18:13:57 +01:00
plperl_query_entry *hash_entry;
Prepared queries for PLPerl, plus fixing a small plperl memory leak. Patch and docs from Dmitry Karasik, slightly editorialised.
2006-03-05 17:40:51 +01:00
SV *cursor;
Portal portal = NULL;
/*
* Execute the query inside a sub-transaction, so we can cope with errors
* sanely
*/
MemoryContext oldcontext = CurrentMemoryContext;
ResourceOwner oldowner = CurrentResourceOwner;
Add plperl.on_perl_init setting to provide for initializing the perl library on load. Also, handle END blocks in plperl. Database access is disallowed during both these operations, although it might be allowed in END blocks in future. Patch from Tim Bunce.
2010-01-30 02:46:57 +01:00
check_spi_usage_allowed();
Prepared queries for PLPerl, plus fixing a small plperl memory leak. Patch and docs from Dmitry Karasik, slightly editorialised.
2006-03-05 17:40:51 +01:00
BeginInternalSubTransaction(NULL);
/* Want to run inside function's memory context */
MemoryContextSwitchTo(oldcontext);
PG_TRY();
{
/************************************************************
* Fetch the saved plan descriptor, see if it's o.k.
************************************************************/
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
hash_entry = hash_search(plperl_active_interp->query_hash, query,
Force plperl and plperlu to run in separate interpreters. Create an error on an attempt to create the second interpreter if this is not supported by the perl installation. Per recent -hackers discussion.
2006-11-13 18:13:57 +01:00
HASH_FIND, NULL);
if (hash_entry == NULL)
Eliminate memory leaks in plperl's spi_prepare() function. Careless use of TopMemoryContext for I/O function data meant that repeated use of spi_prepare and spi_freeplan would leak memory at the session level, as per report from Christian Schröder. In addition, spi_prepare leaked a lot of transient data within the current plperl function's SPI Proc context, which would be a problem for repeated use of spi_prepare within a single plperl function call; and it wasn't terribly careful about releasing permanent allocations in event of an error, either. In passing, clean up some copy-and-pasteos in query-lookup error messages. Alex Hunsaker and Tom Lane
2013-03-02 03:33:34 +01:00
elog(ERROR, "spi_query_prepared: Invalid prepared query passed");
Force plperl and plperlu to run in separate interpreters. Create an error on an attempt to create the second interpreter if this is not supported by the perl installation. Per recent -hackers discussion.
2006-11-13 18:13:57 +01:00
qdesc = hash_entry->query_data;
Prepared queries for PLPerl, plus fixing a small plperl memory leak. Patch and docs from Dmitry Karasik, slightly editorialised.
2006-03-05 17:40:51 +01:00
if (qdesc == NULL)
Eliminate memory leaks in plperl's spi_prepare() function. Careless use of TopMemoryContext for I/O function data meant that repeated use of spi_prepare and spi_freeplan would leak memory at the session level, as per report from Christian Schröder. In addition, spi_prepare leaked a lot of transient data within the current plperl function's SPI Proc context, which would be a problem for repeated use of spi_prepare within a single plperl function call; and it wasn't terribly careful about releasing permanent allocations in event of an error, either. In passing, clean up some copy-and-pasteos in query-lookup error messages. Alex Hunsaker and Tom Lane
2013-03-02 03:33:34 +01:00
elog(ERROR, "spi_query_prepared: plperl query_hash value vanished");
Prepared queries for PLPerl, plus fixing a small plperl memory leak. Patch and docs from Dmitry Karasik, slightly editorialised.
2006-03-05 17:40:51 +01:00
if (qdesc->nargs != argc)
elog(ERROR, "spi_query_prepared: expected %d argument(s), %d passed",
qdesc->nargs, argc);
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
Prepared queries for PLPerl, plus fixing a small plperl memory leak. Patch and docs from Dmitry Karasik, slightly editorialised.
2006-03-05 17:40:51 +01:00
/************************************************************
* Set up arguments
************************************************************/
Modify all callers of datatype input and receive functions so that if these functions are not strict, they will be called (passing a NULL first parameter) during any attempt to input a NULL value of their datatype. Currently, all our input functions are strict and so this commit does not change any behavior. However, this will make it possible to build domain input functions that centralize checking of domain constraints, thereby closing numerous holes in our domain support, as per previous discussion. While at it, I took the opportunity to introduce convenience functions InputFunctionCall, OutputFunctionCall, etc to use in code that calls I/O functions. This eliminates a lot of grotty-looking casts, but the main motivation is to make it easier to grep for these places if we ever need to touch them again.
2006-04-04 21:35:37 +02:00
if (argc > 0)
Prepared queries for PLPerl, plus fixing a small plperl memory leak. Patch and docs from Dmitry Karasik, slightly editorialised.
2006-03-05 17:40:51 +01:00
{
Modify all callers of datatype input and receive functions so that if these functions are not strict, they will be called (passing a NULL first parameter) during any attempt to input a NULL value of their datatype. Currently, all our input functions are strict and so this commit does not change any behavior. However, this will make it possible to build domain input functions that centralize checking of domain constraints, thereby closing numerous holes in our domain support, as per previous discussion. While at it, I took the opportunity to introduce convenience functions InputFunctionCall, OutputFunctionCall, etc to use in code that calls I/O functions. This eliminates a lot of grotty-looking casts, but the main motivation is to make it easier to grep for these places if we ever need to touch them again.
2006-04-04 21:35:37 +02:00
nulls = (char *) palloc(argc);
Prepared queries for PLPerl, plus fixing a small plperl memory leak. Patch and docs from Dmitry Karasik, slightly editorialised.
2006-03-05 17:40:51 +01:00
argvalues = (Datum *) palloc(argc * sizeof(Datum));
}
else
{
nulls = NULL;
argvalues = NULL;
}
Modify all callers of datatype input and receive functions so that if these functions are not strict, they will be called (passing a NULL first parameter) during any attempt to input a NULL value of their datatype. Currently, all our input functions are strict and so this commit does not change any behavior. However, this will make it possible to build domain input functions that centralize checking of domain constraints, thereby closing numerous holes in our domain support, as per previous discussion. While at it, I took the opportunity to introduce convenience functions InputFunctionCall, OutputFunctionCall, etc to use in code that calls I/O functions. This eliminates a lot of grotty-looking casts, but the main motivation is to make it easier to grep for these places if we ever need to touch them again.
2006-04-04 21:35:37 +02:00
for (i = 0; i < argc; i++)
Prepared queries for PLPerl, plus fixing a small plperl memory leak. Patch and docs from Dmitry Karasik, slightly editorialised.
2006-03-05 17:40:51 +01:00
{
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
bool isnull;
argvalues[i] = plperl_sv_to_datum(argv[i],
qdesc->argtypes[i],
Fix up Perl-to-Postgres datatype conversions in pl/perl. This patch restores the pre-9.1 behavior that pl/perl functions returning VOID ignore the result value of their last Perl statement. 9.1.0 unintentionally threw an error if the last statement returned a reference, as reported by Amit Khandekar. Also, make sure it works to return a string value for a composite type, so long as the string meets the type's input format. We already allowed the equivalent behavior for arrays, so it seems inconsistent to not allow it for composites. In addition, ensure we throw errors for attempts to return arrays or hashes when the function's declared result type is not an array or composite type, respectively. Pre-9.1 versions rather uselessly returned strings like ARRAY(0x221a9a0) or HASH(0x221aa90), while 9.1.0 threw an error for the hash case and returned a garbage value for the array case. Also, clean up assorted grotty coding in Perl array conversion, including use of a session-lifespan memory context to accumulate the array value (resulting in session-lifespan memory leak on error), failure to apply the declared typmod if any, and failure to detect some cases of non-rectangular multi-dimensional arrays. Alex Hunsaker and Tom Lane
2011-10-14 00:02:43 +02:00
-1,
NULL,
&qdesc->arginfuncs[i],
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
qdesc->argtypioparams[i],
Fix up Perl-to-Postgres datatype conversions in pl/perl. This patch restores the pre-9.1 behavior that pl/perl functions returning VOID ignore the result value of their last Perl statement. 9.1.0 unintentionally threw an error if the last statement returned a reference, as reported by Amit Khandekar. Also, make sure it works to return a string value for a composite type, so long as the string meets the type's input format. We already allowed the equivalent behavior for arrays, so it seems inconsistent to not allow it for composites. In addition, ensure we throw errors for attempts to return arrays or hashes when the function's declared result type is not an array or composite type, respectively. Pre-9.1 versions rather uselessly returned strings like ARRAY(0x221a9a0) or HASH(0x221aa90), while 9.1.0 threw an error for the hash case and returned a garbage value for the array case. Also, clean up assorted grotty coding in Perl array conversion, including use of a session-lifespan memory context to accumulate the array value (resulting in session-lifespan memory leak on error), failure to apply the declared typmod if any, and failure to detect some cases of non-rectangular multi-dimensional arrays. Alex Hunsaker and Tom Lane
2011-10-14 00:02:43 +02:00
&isnull);
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
2011-02-18 02:11:50 +01:00
nulls[i] = isnull ? 'n' : ' ';
Prepared queries for PLPerl, plus fixing a small plperl memory leak. Patch and docs from Dmitry Karasik, slightly editorialised.
2006-03-05 17:40:51 +01:00
}
/************************************************************
* go
************************************************************/
portal = SPI_cursor_open(NULL, qdesc->plan, argvalues, nulls,
current_call_data->prodesc->fn_readonly);
if (argc > 0)
{
pfree(argvalues);
pfree(nulls);
}
if (portal == NULL)
elog(ERROR, "SPI_cursor_open() failed:%s",
SPI_result_code_string(SPI_result));
Force strings passed to and from plperl to be in UTF8 encoding. String are converted to UTF8 on the way into perl and to the database encoding on the way back. This avoids a number of observed anomalies, and ensures Perl a consistent view of the world. Some minor code cleanups are also accomplished. Alex Hunsaker, reviewed by Andy Colson.
2011-02-06 23:29:26 +01:00
cursor = cstr2sv(portal->name);
Prepared queries for PLPerl, plus fixing a small plperl memory leak. Patch and docs from Dmitry Karasik, slightly editorialised.
2006-03-05 17:40:51 +01:00
Use portal pinning in PL/Perl and PL/Python PL/pgSQL "pins" internally generated portals so that user code cannot close them by guessing their names. Add this functionality to PL/Perl and PL/Python as well, preventing users from manually closing cursors created by spi_query and plpy.cursor, respectively. (PL/Tcl does not currently offer any cursor functionality.)
2017-12-12 16:26:47 +01:00
PinPortal(portal);
Prepared queries for PLPerl, plus fixing a small plperl memory leak. Patch and docs from Dmitry Karasik, slightly editorialised.
2006-03-05 17:40:51 +01:00
/* Commit the inner transaction, return to outer xact context */
ReleaseCurrentSubTransaction();
MemoryContextSwitchTo(oldcontext);
CurrentResourceOwner = oldowner;
}
PG_CATCH();
{
ErrorData *edata;
/* Save error info */
MemoryContextSwitchTo(oldcontext);
edata = CopyErrorData();
FlushErrorState();
/* Abort the inner transaction */
RollbackAndReleaseCurrentSubTransaction();
MemoryContextSwitchTo(oldcontext);
CurrentResourceOwner = oldowner;
/* Punt the error to Perl */
Fix plperl to handle non-ASCII error message texts correctly. We were passing error message texts to croak() verbatim, which turns out not to work if the text contains non-ASCII characters; Perl mangles their encoding, as reported in bug #13638 from Michal Leinweber. To fix, convert the text into a UTF8-encoded SV first. It's hard to test this without risking failures in different database encodings; but we can follow the lead of plpython, which is already assuming that no-break space (U+00A0) has an equivalent in all encodings we care about running the regression tests in (cf commit 2dfa15de5). Back-patch to 9.1. The code is quite different in 9.0, and anyway it seems too risky to put something like this into 9.0's final minor release. Alex Hunsaker, with suggestions from Tim Bunce and Tom Lane
2015-09-29 16:52:22 +02:00
croak_cstr(edata->message);
Prepared queries for PLPerl, plus fixing a small plperl memory leak. Patch and docs from Dmitry Karasik, slightly editorialised.
2006-03-05 17:40:51 +01:00
/* Can't get here, but keep compiler quiet */
return NULL;
}
PG_END_TRY();
return cursor;
}
void
plperl_spi_freeplan(char *query)
{
Redesign the plancache mechanism for more flexibility and efficiency. Rewrite plancache.c so that a "cached plan" (which is rather a misnomer at this point) can support generation of custom, parameter-value-dependent plans, and can make an intelligent choice between using custom plans and the traditional generic-plan approach. The specific choice algorithm implemented here can probably be improved in future, but this commit is all about getting the mechanism in place, not the policy. In addition, restructure the API to greatly reduce the amount of extraneous data copying needed. The main compromise needed to make that possible was to split the initial creation of a CachedPlanSource into two steps. It's worth noting in particular that SPI_saveplan is now deprecated in favor of SPI_keepplan, which accomplishes the same end result with zero data copying, and no need to then spend even more cycles throwing away the original SPIPlan. The risk of long-term memory leaks while manipulating SPIPlans has also been greatly reduced. Most of this improvement is based on use of the recently-added MemoryContextSetParent primitive.
2011-09-16 06:42:53 +02:00
SPIPlanPtr plan;
Prepared queries for PLPerl, plus fixing a small plperl memory leak. Patch and docs from Dmitry Karasik, slightly editorialised.
2006-03-05 17:40:51 +01:00
plperl_query_desc *qdesc;
Force plperl and plperlu to run in separate interpreters. Create an error on an attempt to create the second interpreter if this is not supported by the perl installation. Per recent -hackers discussion.
2006-11-13 18:13:57 +01:00
plperl_query_entry *hash_entry;
Prepared queries for PLPerl, plus fixing a small plperl memory leak. Patch and docs from Dmitry Karasik, slightly editorialised.
2006-03-05 17:40:51 +01:00
Add plperl.on_perl_init setting to provide for initializing the perl library on load. Also, handle END blocks in plperl. Database access is disallowed during both these operations, although it might be allowed in END blocks in future. Patch from Tim Bunce.
2010-01-30 02:46:57 +01:00
check_spi_usage_allowed();
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
hash_entry = hash_search(plperl_active_interp->query_hash, query,
Force plperl and plperlu to run in separate interpreters. Create an error on an attempt to create the second interpreter if this is not supported by the perl installation. Per recent -hackers discussion.
2006-11-13 18:13:57 +01:00
HASH_FIND, NULL);
if (hash_entry == NULL)
Eliminate memory leaks in plperl's spi_prepare() function. Careless use of TopMemoryContext for I/O function data meant that repeated use of spi_prepare and spi_freeplan would leak memory at the session level, as per report from Christian Schröder. In addition, spi_prepare leaked a lot of transient data within the current plperl function's SPI Proc context, which would be a problem for repeated use of spi_prepare within a single plperl function call; and it wasn't terribly careful about releasing permanent allocations in event of an error, either. In passing, clean up some copy-and-pasteos in query-lookup error messages. Alex Hunsaker and Tom Lane
2013-03-02 03:33:34 +01:00
elog(ERROR, "spi_freeplan: Invalid prepared query passed");
Force plperl and plperlu to run in separate interpreters. Create an error on an attempt to create the second interpreter if this is not supported by the perl installation. Per recent -hackers discussion.
2006-11-13 18:13:57 +01:00
qdesc = hash_entry->query_data;
Prepared queries for PLPerl, plus fixing a small plperl memory leak. Patch and docs from Dmitry Karasik, slightly editorialised.
2006-03-05 17:40:51 +01:00
if (qdesc == NULL)
Eliminate memory leaks in plperl's spi_prepare() function. Careless use of TopMemoryContext for I/O function data meant that repeated use of spi_prepare and spi_freeplan would leak memory at the session level, as per report from Christian Schröder. In addition, spi_prepare leaked a lot of transient data within the current plperl function's SPI Proc context, which would be a problem for repeated use of spi_prepare within a single plperl function call; and it wasn't terribly careful about releasing permanent allocations in event of an error, either. In passing, clean up some copy-and-pasteos in query-lookup error messages. Alex Hunsaker and Tom Lane
2013-03-02 03:33:34 +01:00
elog(ERROR, "spi_freeplan: plperl query_hash value vanished");
plan = qdesc->plan;
Prepared queries for PLPerl, plus fixing a small plperl memory leak. Patch and docs from Dmitry Karasik, slightly editorialised.
2006-03-05 17:40:51 +01:00
/*
* free all memory before SPI_freeplan, so if it dies, nothing will be
* left over
*/
Use a separate interpreter for each calling SQL userid in plperl and pltcl. There are numerous methods by which a Perl or Tcl function can subvert the behavior of another such function executed later; for example, by redefining standard functions or operators called by the target function. If the target function is SECURITY DEFINER, or is called by such a function, this means that any ordinary SQL user with Perl or Tcl language usage rights can do essentially anything with the privileges of the target function's owner. To close this security hole, create a separate Perl or Tcl interpreter for each SQL userid under which plperl or pltcl functions are executed within a session. However, all plperlu or pltclu functions run within a session still share a single interpreter, since they all execute at the trust level of a database superuser anyway. Note: this change results in a functionality loss when libperl has been built without the "multiplicity" option: it's no longer possible to call plperl functions under different userids in one session, since such a libperl can't support multiple interpreters in one process. However, such a libperl already failed to support concurrent use of plperl and plperlu, so it's likely that few people use such versions with Postgres. Security: CVE-2010-3433
2010-09-30 23:18:51 +02:00
hash_search(plperl_active_interp->query_hash, query,
Combine cmin and cmax fields of HeapTupleHeaders into a single field, by keeping private state in each backend that has inserted and deleted the same tuple during its current top-level transaction. This is sufficient since there is no need to be able to determine the cmin/cmax from any other transaction. This gets us back down to 23-byte headers, removing a penalty paid in 8.0 to support subtransactions. Patch by Heikki Linnakangas, with minor revisions by moi, following a design hashed out awhile back on the pghackers list.
2007-02-09 04:35:35 +01:00
HASH_REMOVE, NULL);
Force plperl and plperlu to run in separate interpreters. Create an error on an attempt to create the second interpreter if this is not supported by the perl installation. Per recent -hackers discussion.
2006-11-13 18:13:57 +01:00
Eliminate memory leaks in plperl's spi_prepare() function. Careless use of TopMemoryContext for I/O function data meant that repeated use of spi_prepare and spi_freeplan would leak memory at the session level, as per report from Christian Schröder. In addition, spi_prepare leaked a lot of transient data within the current plperl function's SPI Proc context, which would be a problem for repeated use of spi_prepare within a single plperl function call; and it wasn't terribly careful about releasing permanent allocations in event of an error, either. In passing, clean up some copy-and-pasteos in query-lookup error messages. Alex Hunsaker and Tom Lane
2013-03-02 03:33:34 +01:00
MemoryContextDelete(qdesc->plan_cxt);
Prepared queries for PLPerl, plus fixing a small plperl memory leak. Patch and docs from Dmitry Karasik, slightly editorialised.
2006-03-05 17:40:51 +01:00
SPI_freeplan(plan);
}
Adjust plperl to ensure that all strings and hash keys passed to Perl are marked as UTF8 when the database encoding is UTF8. This should avoid inconsistencies like that exhibited in bug #2683 from Vitali Stupin.
2006-10-15 20:56:39 +02:00
Transaction control in PL procedures In each of the supplied procedural languages (PL/pgSQL, PL/Perl, PL/Python, PL/Tcl), add language-specific commit and rollback functions/commands to control transactions in procedures in that language. Add similar underlying functions to SPI. Some additional cleanup so that transaction commit or abort doesn't blow away data structures still used by the procedure call. Add execution context tracking to CALL and DO statements so that transaction control commands can only be issued in top-level procedure and block calls, not function calls or other procedure or block calls. - SPI Add a new function SPI_connect_ext() that is like SPI_connect() but allows passing option flags. The only option flag right now is SPI_OPT_NONATOMIC. A nonatomic SPI connection can execute transaction control commands, otherwise it's not allowed. This is meant to be passed down from CALL and DO statements which themselves know in which context they are called. A nonatomic SPI connection uses different memory management. A normal SPI connection allocates its memory in TopTransactionContext. For nonatomic connections we use PortalContext instead. As the comment in SPI_connect_ext() (previously SPI_connect()) indicates, one could potentially use PortalContext in all cases, but it seems safest to leave the existing uses alone, because this stuff is complicated enough already. SPI also gets new functions SPI_start_transaction(), SPI_commit(), and SPI_rollback(), which can be used by PLs to implement their transaction control logic. - portalmem.c Some adjustments were made in the code that cleans up portals at transaction abort. The portal code could already handle a command *committing* a transaction and continuing (e.g., VACUUM), but it was not quite prepared for a command *aborting* a transaction and continuing. In AtAbort_Portals(), remove the code that marks an active portal as failed. As the comment there already predicted, this doesn't work if the running command wants to keep running after transaction abort. And it's actually not necessary, because pquery.c is careful to run all portal code in a PG_TRY block and explicitly runs MarkPortalFailed() if there is an exception. So the code in AtAbort_Portals() is never used anyway. In AtAbort_Portals() and AtCleanup_Portals(), we need to be careful not to clean up active portals too much. This mirrors similar code in PreCommit_Portals(). - PL/Perl Gets new functions spi_commit() and spi_rollback() - PL/pgSQL Gets new commands COMMIT and ROLLBACK. Update the PL/SQL porting example in the documentation to reflect that transactions are now possible in procedures. - PL/Python Gets new functions plpy.commit and plpy.rollback. - PL/Tcl Gets new commands commit and rollback. Reviewed-by: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
2018-01-22 14:30:16 +01:00
void
plperl_spi_commit(void)
{
MemoryContext oldcontext = CurrentMemoryContext;
Disallow execution of SPI functions during plperl function compilation. Perl can be convinced to execute user-defined code during compilation of a plperl function (or at least a plperlu function). That's not such a big problem as long as the activity is confined within the Perl interpreter, and it's not clear we could do anything about that anyway. However, if such code tries to use plperl's SPI functions, we have a bigger problem. In the first place, those functions are likely to crash because current_call_data->prodesc isn't set up yet. In the second place, because it isn't set up, we lack critical info such as whether the function is supposed to be read-only. And in the third place, this path allows code execution during function validation, which is strongly discouraged because of the potential for security exploits. Hence, reject execution of the SPI functions until compilation is finished. While here, add check_spi_usage_allowed() calls to various functions that hadn't gotten the memo about checking that. I think that perhaps plperl_sv_to_literal may have been intentionally omitted on the grounds that it was safe at the time; but if so, the addition of transforms functionality changed that. The others are more recently added and seem to be flat-out oversights. Per report from Mark Murawski. Back-patch to all supported branches. Discussion: https://postgr.es/m/9acdf918-7fff-4f40-f750-2ffa84f083d2@intellasoft.net
2022-02-25 23:40:21 +01:00
check_spi_usage_allowed();
Transaction control in PL procedures In each of the supplied procedural languages (PL/pgSQL, PL/Perl, PL/Python, PL/Tcl), add language-specific commit and rollback functions/commands to control transactions in procedures in that language. Add similar underlying functions to SPI. Some additional cleanup so that transaction commit or abort doesn't blow away data structures still used by the procedure call. Add execution context tracking to CALL and DO statements so that transaction control commands can only be issued in top-level procedure and block calls, not function calls or other procedure or block calls. - SPI Add a new function SPI_connect_ext() that is like SPI_connect() but allows passing option flags. The only option flag right now is SPI_OPT_NONATOMIC. A nonatomic SPI connection can execute transaction control commands, otherwise it's not allowed. This is meant to be passed down from CALL and DO statements which themselves know in which context they are called. A nonatomic SPI connection uses different memory management. A normal SPI connection allocates its memory in TopTransactionContext. For nonatomic connections we use PortalContext instead. As the comment in SPI_connect_ext() (previously SPI_connect()) indicates, one could potentially use PortalContext in all cases, but it seems safest to leave the existing uses alone, because this stuff is complicated enough already. SPI also gets new functions SPI_start_transaction(), SPI_commit(), and SPI_rollback(), which can be used by PLs to implement their transaction control logic. - portalmem.c Some adjustments were made in the code that cleans up portals at transaction abort. The portal code could already handle a command *committing* a transaction and continuing (e.g., VACUUM), but it was not quite prepared for a command *aborting* a transaction and continuing. In AtAbort_Portals(), remove the code that marks an active portal as failed. As the comment there already predicted, this doesn't work if the running command wants to keep running after transaction abort. And it's actually not necessary, because pquery.c is careful to run all portal code in a PG_TRY block and explicitly runs MarkPortalFailed() if there is an exception. So the code in AtAbort_Portals() is never used anyway. In AtAbort_Portals() and AtCleanup_Portals(), we need to be careful not to clean up active portals too much. This mirrors similar code in PreCommit_Portals(). - PL/Perl Gets new functions spi_commit() and spi_rollback() - PL/pgSQL Gets new commands COMMIT and ROLLBACK. Update the PL/SQL porting example in the documentation to reflect that transactions are now possible in procedures. - PL/Python Gets new functions plpy.commit and plpy.rollback. - PL/Tcl Gets new commands commit and rollback. Reviewed-by: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
2018-01-22 14:30:16 +01:00
PG_TRY();
{
SPI_commit();
}
PG_CATCH();
{
ErrorData *edata;
/* Save error info */
MemoryContextSwitchTo(oldcontext);
edata = CopyErrorData();
FlushErrorState();
/* Punt the error to Perl */
croak_cstr(edata->message);
}
PG_END_TRY();
}
void
plperl_spi_rollback(void)
{
MemoryContext oldcontext = CurrentMemoryContext;
Disallow execution of SPI functions during plperl function compilation. Perl can be convinced to execute user-defined code during compilation of a plperl function (or at least a plperlu function). That's not such a big problem as long as the activity is confined within the Perl interpreter, and it's not clear we could do anything about that anyway. However, if such code tries to use plperl's SPI functions, we have a bigger problem. In the first place, those functions are likely to crash because current_call_data->prodesc isn't set up yet. In the second place, because it isn't set up, we lack critical info such as whether the function is supposed to be read-only. And in the third place, this path allows code execution during function validation, which is strongly discouraged because of the potential for security exploits. Hence, reject execution of the SPI functions until compilation is finished. While here, add check_spi_usage_allowed() calls to various functions that hadn't gotten the memo about checking that. I think that perhaps plperl_sv_to_literal may have been intentionally omitted on the grounds that it was safe at the time; but if so, the addition of transforms functionality changed that. The others are more recently added and seem to be flat-out oversights. Per report from Mark Murawski. Back-patch to all supported branches. Discussion: https://postgr.es/m/9acdf918-7fff-4f40-f750-2ffa84f083d2@intellasoft.net
2022-02-25 23:40:21 +01:00
check_spi_usage_allowed();
Transaction control in PL procedures In each of the supplied procedural languages (PL/pgSQL, PL/Perl, PL/Python, PL/Tcl), add language-specific commit and rollback functions/commands to control transactions in procedures in that language. Add similar underlying functions to SPI. Some additional cleanup so that transaction commit or abort doesn't blow away data structures still used by the procedure call. Add execution context tracking to CALL and DO statements so that transaction control commands can only be issued in top-level procedure and block calls, not function calls or other procedure or block calls. - SPI Add a new function SPI_connect_ext() that is like SPI_connect() but allows passing option flags. The only option flag right now is SPI_OPT_NONATOMIC. A nonatomic SPI connection can execute transaction control commands, otherwise it's not allowed. This is meant to be passed down from CALL and DO statements which themselves know in which context they are called. A nonatomic SPI connection uses different memory management. A normal SPI connection allocates its memory in TopTransactionContext. For nonatomic connections we use PortalContext instead. As the comment in SPI_connect_ext() (previously SPI_connect()) indicates, one could potentially use PortalContext in all cases, but it seems safest to leave the existing uses alone, because this stuff is complicated enough already. SPI also gets new functions SPI_start_transaction(), SPI_commit(), and SPI_rollback(), which can be used by PLs to implement their transaction control logic. - portalmem.c Some adjustments were made in the code that cleans up portals at transaction abort. The portal code could already handle a command *committing* a transaction and continuing (e.g., VACUUM), but it was not quite prepared for a command *aborting* a transaction and continuing. In AtAbort_Portals(), remove the code that marks an active portal as failed. As the comment there already predicted, this doesn't work if the running command wants to keep running after transaction abort. And it's actually not necessary, because pquery.c is careful to run all portal code in a PG_TRY block and explicitly runs MarkPortalFailed() if there is an exception. So the code in AtAbort_Portals() is never used anyway. In AtAbort_Portals() and AtCleanup_Portals(), we need to be careful not to clean up active portals too much. This mirrors similar code in PreCommit_Portals(). - PL/Perl Gets new functions spi_commit() and spi_rollback() - PL/pgSQL Gets new commands COMMIT and ROLLBACK. Update the PL/SQL porting example in the documentation to reflect that transactions are now possible in procedures. - PL/Python Gets new functions plpy.commit and plpy.rollback. - PL/Tcl Gets new commands commit and rollback. Reviewed-by: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
2018-01-22 14:30:16 +01:00
PG_TRY();
{
SPI_rollback();
}
PG_CATCH();
{
ErrorData *edata;
/* Save error info */
MemoryContextSwitchTo(oldcontext);
edata = CopyErrorData();
FlushErrorState();
/* Punt the error to Perl */
croak_cstr(edata->message);
}
PG_END_TRY();
}
PL/Perl portability fix: avoid including XSUB.h in plperl.c. In Perl builds that define PERL_IMPLICIT_SYS, XSUB.h defines macros that replace a whole lot of basic libc functions with Perl functions. We can't tolerate that in plperl.c; it breaks at least PG_TRY and probably other stuff. The core idea of this patch is to include XSUB.h only in the .xs files where it's really needed, and to move any code broken by PERL_IMPLICIT_SYS out of the .xs files and into plperl.c. The reason this hasn't been a problem before is that our build techniques did not result in PERL_IMPLICIT_SYS appearing as a #define in PL/Perl, even on some platforms where Perl thinks it is defined. That's about to change in order to fix a nasty portability issue, so we need this work to make the code safe for that. Rather unaccountably, the Perl people chose XSUB.h as the place to provide the versions of the aTHX/aTHX_ macros that are needed by code that's not explicitly aware of the MULTIPLICITY API conventions. Hence, just removing XSUB.h from plperl.c fails miserably. But we can work around that by defining PERL_NO_GET_CONTEXT (which would make the relevant stanza of XSUB.h a no-op anyway). As explained in perlguts.pod, that means we need to add a "dTHX" macro call in every C function that calls a Perl API function. In most of them we just add this at the top; but since the macro fetches the current Perl interpreter pointer, more care is needed in functions that switch the active interpreter. Lack of the macro is easily recognized since it results in bleats about "my_perl" not being defined. (A nice side benefit of this is that it significantly reduces the number of fetches of the current interpreter pointer. On my machine, plperl.so gets more than 10% smaller, and there's probably some performance win too. We could reduce the number of fetches still more by decorating the code with pTHX_/aTHX_ macros to pass the interpreter pointer around, as explained by perlguts.pod; but that's a task for another day.) Formatting note: pgindent seems happy to treat "dTHX;" as a declaration so long as it's the first thing after the left brace, as we'd already observed with respect to the similar macro "dSP;". If you try to put it later in a set of declarations, pgindent puts ugly extra space around it. Having removed XSUB.h from plperl.c, we need only move the support functions for spi_return_next and util_elog (both of which use PG_TRY) out of the .xs files and into plperl.c. This seems sufficient to avoid the known problems caused by PERL_IMPLICIT_SYS, although we could move more code if additional issues emerge. This will need to be back-patched, but first let's see what the buildfarm makes of it. Patch by me, with some help from Ashutosh Sharma Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
2017-07-28 18:25:43 +02:00
/*
* Implementation of plperl's elog() function
*
* If the error level is less than ERROR, we'll just emit the message and
* return. When it is ERROR, elog() will longjmp, which we catch and
* turn into a Perl croak(). Note we are assuming that elog() can't have
* any internal failures that are so bad as to require a transaction abort.
*
* The main reason this is out-of-line is to avoid conflicts between XSUB.h
* and the PG_TRY macros.
*/
void
plperl_util_elog(int level, SV *msg)
{
MemoryContext oldcontext = CurrentMemoryContext;
char *volatile cmsg = NULL;
Disallow execution of SPI functions during plperl function compilation. Perl can be convinced to execute user-defined code during compilation of a plperl function (or at least a plperlu function). That's not such a big problem as long as the activity is confined within the Perl interpreter, and it's not clear we could do anything about that anyway. However, if such code tries to use plperl's SPI functions, we have a bigger problem. In the first place, those functions are likely to crash because current_call_data->prodesc isn't set up yet. In the second place, because it isn't set up, we lack critical info such as whether the function is supposed to be read-only. And in the third place, this path allows code execution during function validation, which is strongly discouraged because of the potential for security exploits. Hence, reject execution of the SPI functions until compilation is finished. While here, add check_spi_usage_allowed() calls to various functions that hadn't gotten the memo about checking that. I think that perhaps plperl_sv_to_literal may have been intentionally omitted on the grounds that it was safe at the time; but if so, the addition of transforms functionality changed that. The others are more recently added and seem to be flat-out oversights. Per report from Mark Murawski. Back-patch to all supported branches. Discussion: https://postgr.es/m/9acdf918-7fff-4f40-f750-2ffa84f083d2@intellasoft.net
2022-02-25 23:40:21 +01:00
/*
* We intentionally omit check_spi_usage_allowed() here, as this seems
* safe to allow even in the contexts that that function rejects.
*/
PL/Perl portability fix: avoid including XSUB.h in plperl.c. In Perl builds that define PERL_IMPLICIT_SYS, XSUB.h defines macros that replace a whole lot of basic libc functions with Perl functions. We can't tolerate that in plperl.c; it breaks at least PG_TRY and probably other stuff. The core idea of this patch is to include XSUB.h only in the .xs files where it's really needed, and to move any code broken by PERL_IMPLICIT_SYS out of the .xs files and into plperl.c. The reason this hasn't been a problem before is that our build techniques did not result in PERL_IMPLICIT_SYS appearing as a #define in PL/Perl, even on some platforms where Perl thinks it is defined. That's about to change in order to fix a nasty portability issue, so we need this work to make the code safe for that. Rather unaccountably, the Perl people chose XSUB.h as the place to provide the versions of the aTHX/aTHX_ macros that are needed by code that's not explicitly aware of the MULTIPLICITY API conventions. Hence, just removing XSUB.h from plperl.c fails miserably. But we can work around that by defining PERL_NO_GET_CONTEXT (which would make the relevant stanza of XSUB.h a no-op anyway). As explained in perlguts.pod, that means we need to add a "dTHX" macro call in every C function that calls a Perl API function. In most of them we just add this at the top; but since the macro fetches the current Perl interpreter pointer, more care is needed in functions that switch the active interpreter. Lack of the macro is easily recognized since it results in bleats about "my_perl" not being defined. (A nice side benefit of this is that it significantly reduces the number of fetches of the current interpreter pointer. On my machine, plperl.so gets more than 10% smaller, and there's probably some performance win too. We could reduce the number of fetches still more by decorating the code with pTHX_/aTHX_ macros to pass the interpreter pointer around, as explained by perlguts.pod; but that's a task for another day.) Formatting note: pgindent seems happy to treat "dTHX;" as a declaration so long as it's the first thing after the left brace, as we'd already observed with respect to the similar macro "dSP;". If you try to put it later in a set of declarations, pgindent puts ugly extra space around it. Having removed XSUB.h from plperl.c, we need only move the support functions for spi_return_next and util_elog (both of which use PG_TRY) out of the .xs files and into plperl.c. This seems sufficient to avoid the known problems caused by PERL_IMPLICIT_SYS, although we could move more code if additional issues emerge. This will need to be back-patched, but first let's see what the buildfarm makes of it. Patch by me, with some help from Ashutosh Sharma Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
2017-07-28 18:25:43 +02:00
PG_TRY();
{
cmsg = sv2cstr(msg);
elog(level, "%s", cmsg);
pfree(cmsg);
}
PG_CATCH();
{
ErrorData *edata;
/* Must reset elog.c's state */
MemoryContextSwitchTo(oldcontext);
edata = CopyErrorData();
FlushErrorState();
if (cmsg)
pfree(cmsg);
/* Punt the error to Perl */
croak_cstr(edata->message);
}
PG_END_TRY();
}
Adjust plperl to ensure that all strings and hash keys passed to Perl are marked as UTF8 when the database encoding is UTF8. This should avoid inconsistencies like that exhibited in bug #2683 from Vitali Stupin.
2006-10-15 20:56:39 +02:00
/*
* Store an SV into a hash table under a key that is a string assumed to be
* in the current database's encoding.
*/
static SV **
hv_store_string(HV *hv, const char *key, SV *val)
{
PL/Perl portability fix: avoid including XSUB.h in plperl.c. In Perl builds that define PERL_IMPLICIT_SYS, XSUB.h defines macros that replace a whole lot of basic libc functions with Perl functions. We can't tolerate that in plperl.c; it breaks at least PG_TRY and probably other stuff. The core idea of this patch is to include XSUB.h only in the .xs files where it's really needed, and to move any code broken by PERL_IMPLICIT_SYS out of the .xs files and into plperl.c. The reason this hasn't been a problem before is that our build techniques did not result in PERL_IMPLICIT_SYS appearing as a #define in PL/Perl, even on some platforms where Perl thinks it is defined. That's about to change in order to fix a nasty portability issue, so we need this work to make the code safe for that. Rather unaccountably, the Perl people chose XSUB.h as the place to provide the versions of the aTHX/aTHX_ macros that are needed by code that's not explicitly aware of the MULTIPLICITY API conventions. Hence, just removing XSUB.h from plperl.c fails miserably. But we can work around that by defining PERL_NO_GET_CONTEXT (which would make the relevant stanza of XSUB.h a no-op anyway). As explained in perlguts.pod, that means we need to add a "dTHX" macro call in every C function that calls a Perl API function. In most of them we just add this at the top; but since the macro fetches the current Perl interpreter pointer, more care is needed in functions that switch the active interpreter. Lack of the macro is easily recognized since it results in bleats about "my_perl" not being defined. (A nice side benefit of this is that it significantly reduces the number of fetches of the current interpreter pointer. On my machine, plperl.so gets more than 10% smaller, and there's probably some performance win too. We could reduce the number of fetches still more by decorating the code with pTHX_/aTHX_ macros to pass the interpreter pointer around, as explained by perlguts.pod; but that's a task for another day.) Formatting note: pgindent seems happy to treat "dTHX;" as a declaration so long as it's the first thing after the left brace, as we'd already observed with respect to the similar macro "dSP;". If you try to put it later in a set of declarations, pgindent puts ugly extra space around it. Having removed XSUB.h from plperl.c, we need only move the support functions for spi_return_next and util_elog (both of which use PG_TRY) out of the .xs files and into plperl.c. This seems sufficient to avoid the known problems caused by PERL_IMPLICIT_SYS, although we could move more code if additional issues emerge. This will need to be back-patched, but first let's see what the buildfarm makes of it. Patch by me, with some help from Ashutosh Sharma Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
2017-07-28 18:25:43 +02:00
dTHX;
Force strings passed to and from plperl to be in UTF8 encoding. String are converted to UTF8 on the way into perl and to the database encoding on the way back. This avoids a number of observed anomalies, and ensures Perl a consistent view of the world. Some minor code cleanups are also accomplished. Alex Hunsaker, reviewed by Andy Colson.
2011-02-06 23:29:26 +01:00
int32 hlen;
pgindent run on plperl.c
2011-02-17 20:40:13 +01:00
char *hkey;
SV **ret;
Force strings passed to and from plperl to be in UTF8 encoding. String are converted to UTF8 on the way into perl and to the database encoding on the way back. This avoids a number of observed anomalies, and ensures Perl a consistent view of the world. Some minor code cleanups are also accomplished. Alex Hunsaker, reviewed by Andy Colson.
2011-02-06 23:29:26 +01:00
Prefer pg_any_to_server/pg_server_to_any over pg_do_encoding_conversion. A large majority of the callers of pg_do_encoding_conversion were specifying the database encoding as either source or target of the conversion, meaning that we can use the less general functions pg_any_to_server/pg_server_to_any instead. The main advantage of using the latter functions is that they can make use of a cached conversion-function lookup in the common case that the other encoding is the current client_encoding. It's notationally cleaner too in most cases, not least because of the historical artifact that the latter functions use "char *" rather than "unsigned char *" in their APIs. Note that pg_any_to_server will apply an encoding verification step in some cases where pg_do_encoding_conversion would have just done nothing. This seems to me to be a good idea at most of these call sites, though it partially negates the performance benefit. Per discussion of bug #9210.
2014-02-23 22:59:05 +01:00
hkey = pg_server_to_any(key, strlen(key), PG_UTF8);
Adjust plperl to ensure that all strings and hash keys passed to Perl are marked as UTF8 when the database encoding is UTF8. This should avoid inconsistencies like that exhibited in bug #2683 from Vitali Stupin.
2006-10-15 20:56:39 +02:00
/*
Update PL/Perl's comment about hv_store(). Negative klen is documented since Perl 5.16, and 5.6 is no longer supported so no need to comment about it. Dagfinn Ilmari Mannsåker
2016-03-14 19:45:45 +01:00
* hv_store() recognizes a negative klen parameter as meaning a UTF-8
* encoded key.
Adjust plperl to ensure that all strings and hash keys passed to Perl are marked as UTF8 when the database encoding is UTF8. This should avoid inconsistencies like that exhibited in bug #2683 from Vitali Stupin.
2006-10-15 20:56:39 +02:00
*/
Assorted minor changes to silence Windows compiler warnings. Mostly to do with macro redefinitions or object signedness.
2011-04-25 18:56:53 +02:00
hlen = -(int) strlen(hkey);
Force strings passed to and from plperl to be in UTF8 encoding. String are converted to UTF8 on the way into perl and to the database encoding on the way back. This avoids a number of observed anomalies, and ensures Perl a consistent view of the world. Some minor code cleanups are also accomplished. Alex Hunsaker, reviewed by Andy Colson.
2011-02-06 23:29:26 +01:00
ret = hv_store(hv, hkey, hlen, val, 0);
if (hkey != key)
pfree(hkey);
return ret;
Adjust plperl to ensure that all strings and hash keys passed to Perl are marked as UTF8 when the database encoding is UTF8. This should avoid inconsistencies like that exhibited in bug #2683 from Vitali Stupin.
2006-10-15 20:56:39 +02:00
}
/*
* Fetch an SV from a hash table under a key that is a string assumed to be
* in the current database's encoding.
*/
static SV **
hv_fetch_string(HV *hv, const char *key)
{
PL/Perl portability fix: avoid including XSUB.h in plperl.c. In Perl builds that define PERL_IMPLICIT_SYS, XSUB.h defines macros that replace a whole lot of basic libc functions with Perl functions. We can't tolerate that in plperl.c; it breaks at least PG_TRY and probably other stuff. The core idea of this patch is to include XSUB.h only in the .xs files where it's really needed, and to move any code broken by PERL_IMPLICIT_SYS out of the .xs files and into plperl.c. The reason this hasn't been a problem before is that our build techniques did not result in PERL_IMPLICIT_SYS appearing as a #define in PL/Perl, even on some platforms where Perl thinks it is defined. That's about to change in order to fix a nasty portability issue, so we need this work to make the code safe for that. Rather unaccountably, the Perl people chose XSUB.h as the place to provide the versions of the aTHX/aTHX_ macros that are needed by code that's not explicitly aware of the MULTIPLICITY API conventions. Hence, just removing XSUB.h from plperl.c fails miserably. But we can work around that by defining PERL_NO_GET_CONTEXT (which would make the relevant stanza of XSUB.h a no-op anyway). As explained in perlguts.pod, that means we need to add a "dTHX" macro call in every C function that calls a Perl API function. In most of them we just add this at the top; but since the macro fetches the current Perl interpreter pointer, more care is needed in functions that switch the active interpreter. Lack of the macro is easily recognized since it results in bleats about "my_perl" not being defined. (A nice side benefit of this is that it significantly reduces the number of fetches of the current interpreter pointer. On my machine, plperl.so gets more than 10% smaller, and there's probably some performance win too. We could reduce the number of fetches still more by decorating the code with pTHX_/aTHX_ macros to pass the interpreter pointer around, as explained by perlguts.pod; but that's a task for another day.) Formatting note: pgindent seems happy to treat "dTHX;" as a declaration so long as it's the first thing after the left brace, as we'd already observed with respect to the similar macro "dSP;". If you try to put it later in a set of declarations, pgindent puts ugly extra space around it. Having removed XSUB.h from plperl.c, we need only move the support functions for spi_return_next and util_elog (both of which use PG_TRY) out of the .xs files and into plperl.c. This seems sufficient to avoid the known problems caused by PERL_IMPLICIT_SYS, although we could move more code if additional issues emerge. This will need to be back-patched, but first let's see what the buildfarm makes of it. Patch by me, with some help from Ashutosh Sharma Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
2017-07-28 18:25:43 +02:00
dTHX;
Force strings passed to and from plperl to be in UTF8 encoding. String are converted to UTF8 on the way into perl and to the database encoding on the way back. This avoids a number of observed anomalies, and ensures Perl a consistent view of the world. Some minor code cleanups are also accomplished. Alex Hunsaker, reviewed by Andy Colson.
2011-02-06 23:29:26 +01:00
int32 hlen;
pgindent run on plperl.c
2011-02-17 20:40:13 +01:00
char *hkey;
SV **ret;
Force strings passed to and from plperl to be in UTF8 encoding. String are converted to UTF8 on the way into perl and to the database encoding on the way back. This avoids a number of observed anomalies, and ensures Perl a consistent view of the world. Some minor code cleanups are also accomplished. Alex Hunsaker, reviewed by Andy Colson.
2011-02-06 23:29:26 +01:00
Prefer pg_any_to_server/pg_server_to_any over pg_do_encoding_conversion. A large majority of the callers of pg_do_encoding_conversion were specifying the database encoding as either source or target of the conversion, meaning that we can use the less general functions pg_any_to_server/pg_server_to_any instead. The main advantage of using the latter functions is that they can make use of a cached conversion-function lookup in the common case that the other encoding is the current client_encoding. It's notationally cleaner too in most cases, not least because of the historical artifact that the latter functions use "char *" rather than "unsigned char *" in their APIs. Note that pg_any_to_server will apply an encoding verification step in some cases where pg_do_encoding_conversion would have just done nothing. This seems to me to be a good idea at most of these call sites, though it partially negates the performance benefit. Per discussion of bug #9210.
2014-02-23 22:59:05 +01:00
hkey = pg_server_to_any(key, strlen(key), PG_UTF8);
Adjust plperl to ensure that all strings and hash keys passed to Perl are marked as UTF8 when the database encoding is UTF8. This should avoid inconsistencies like that exhibited in bug #2683 from Vitali Stupin.
2006-10-15 20:56:39 +02:00
/* See notes in hv_store_string */
Assorted minor changes to silence Windows compiler warnings. Mostly to do with macro redefinitions or object signedness.
2011-04-25 18:56:53 +02:00
hlen = -(int) strlen(hkey);
Force strings passed to and from plperl to be in UTF8 encoding. String are converted to UTF8 on the way into perl and to the database encoding on the way back. This avoids a number of observed anomalies, and ensures Perl a consistent view of the world. Some minor code cleanups are also accomplished. Alex Hunsaker, reviewed by Andy Colson.
2011-02-06 23:29:26 +01:00
ret = hv_fetch(hv, hkey, hlen, 0);
pgindent run on plperl.c
2011-02-17 20:40:13 +01:00
if (hkey != key)
Force strings passed to and from plperl to be in UTF8 encoding. String are converted to UTF8 on the way into perl and to the database encoding on the way back. This avoids a number of observed anomalies, and ensures Perl a consistent view of the world. Some minor code cleanups are also accomplished. Alex Hunsaker, reviewed by Andy Colson.
2011-02-06 23:29:26 +01:00
pfree(hkey);
return ret;
Adjust plperl to ensure that all strings and hash keys passed to Perl are marked as UTF8 when the database encoding is UTF8. This should avoid inconsistencies like that exhibited in bug #2683 from Vitali Stupin.
2006-10-15 20:56:39 +02:00
}
errcontext support in PL/Perl Author: Alexey Klyukin <alexk@commandprompt.com>
2009-09-16 08:06:12 +02:00
/*
Add support for anonymous code blocks (DO blocks) to PL/Perl. Joshua Tolley, reviewed by Brendan Jurd and Tim Bunce
2009-11-29 04:02:27 +01:00
* Provide function name for PL/Perl execution errors
errcontext support in PL/Perl Author: Alexey Klyukin <alexk@commandprompt.com>
2009-09-16 08:06:12 +02:00
*/
Add support for anonymous code blocks (DO blocks) to PL/Perl. Joshua Tolley, reviewed by Brendan Jurd and Tim Bunce
2009-11-29 04:02:27 +01:00
static void
errcontext support in PL/Perl Author: Alexey Klyukin <alexk@commandprompt.com>
2009-09-16 08:06:12 +02:00
plperl_exec_callback(void *arg)
{
char *procname = (char *) arg;
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
errcontext support in PL/Perl Author: Alexey Klyukin <alexk@commandprompt.com>
2009-09-16 08:06:12 +02:00
if (procname)
errcontext("PL/Perl function \"%s\"", procname);
}
/*
Add support for anonymous code blocks (DO blocks) to PL/Perl. Joshua Tolley, reviewed by Brendan Jurd and Tim Bunce
2009-11-29 04:02:27 +01:00
* Provide function name for PL/Perl compilation errors
errcontext support in PL/Perl Author: Alexey Klyukin <alexk@commandprompt.com>
2009-09-16 08:06:12 +02:00
*/
static void
plperl_compile_callback(void *arg)
{
char *procname = (char *) arg;
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
errcontext support in PL/Perl Author: Alexey Klyukin <alexk@commandprompt.com>
2009-09-16 08:06:12 +02:00
if (procname)
errcontext("compilation of PL/Perl function \"%s\"", procname);
}
Add support for anonymous code blocks (DO blocks) to PL/Perl. Joshua Tolley, reviewed by Brendan Jurd and Tim Bunce
2009-11-29 04:02:27 +01:00
/*
* Provide error context for the inline handler
*/
static void
plperl_inline_callback(void *arg)
{
errcontext("PL/Perl anonymous code block");
}
Abandon the use of Perl's Safe.pm to enforce restrictions in plperl, as it is fundamentally insecure. Instead apply an opmask to the whole interpreter that imposes restrictions on unsafe operations. These restrictions are much harder to subvert than is Safe.pm, since there is no container to be broken out of. Backported to release 7.4. In releases 7.4, 8.0 and 8.1 this also includes the necessary backporting of the two interpreters model for plperl and plperlu adopted in release 8.2. In versions 8.0 and up, the use of Perl's POSIX module to undo its locale mangling on Windows has become insecure with these changes, so it is replaced by our own routine, which is also faster. Nice side effects of the changes include that it is now possible to use perl's "strict" pragma in a natural way in plperl, and that perl's $a and $b variables now work as expected in sort routines, and that function compilation is significantly faster. Tim Bunce and Andrew Dunstan, with reviews from Alex Hunsaker and Alexey Klyukin. Security: CVE-2010-1169
2010-05-13 18:39:43 +02:00
/*
Copyedit comments and documentation.
2016-04-02 03:53:10 +02:00
* Perl's own setlocale(), copied from POSIX.xs
Abandon the use of Perl's Safe.pm to enforce restrictions in plperl, as it is fundamentally insecure. Instead apply an opmask to the whole interpreter that imposes restrictions on unsafe operations. These restrictions are much harder to subvert than is Safe.pm, since there is no container to be broken out of. Backported to release 7.4. In releases 7.4, 8.0 and 8.1 this also includes the necessary backporting of the two interpreters model for plperl and plperlu adopted in release 8.2. In versions 8.0 and up, the use of Perl's POSIX module to undo its locale mangling on Windows has become insecure with these changes, so it is replaced by our own routine, which is also faster. Nice side effects of the changes include that it is now possible to use perl's "strict" pragma in a natural way in plperl, and that perl's $a and $b variables now work as expected in sort routines, and that function compilation is significantly faster. Tim Bunce and Andrew Dunstan, with reviews from Alex Hunsaker and Alexey Klyukin. Security: CVE-2010-1169
2010-05-13 18:39:43 +02:00
* (needed because of the calls to new_*())
plperl: windows: Use Perl_setlocale on 5.28+, fixing compile failure. For older versions we need our own copy of perl's setlocale(), because it was not exposed (why we need the setlocale in the first place is explained in plperl_init_interp) . The copy stopped working in 5.28, as some of the used macros are not public anymore. But Perl_setlocale is available in 5.28, so use that. Author: Victor Wagner <vitus@wagner.pp.ru> Reviewed-By: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Discussion: https://postgr.es/m/20200501134711.08750c5f@antares.wagner.home Backpatch: all versions
2022-01-30 23:29:04 +01:00
*
* Starting in 5.28, perl exposes Perl_setlocale to do so.
Abandon the use of Perl's Safe.pm to enforce restrictions in plperl, as it is fundamentally insecure. Instead apply an opmask to the whole interpreter that imposes restrictions on unsafe operations. These restrictions are much harder to subvert than is Safe.pm, since there is no container to be broken out of. Backported to release 7.4. In releases 7.4, 8.0 and 8.1 this also includes the necessary backporting of the two interpreters model for plperl and plperlu adopted in release 8.2. In versions 8.0 and up, the use of Perl's POSIX module to undo its locale mangling on Windows has become insecure with these changes, so it is replaced by our own routine, which is also faster. Nice side effects of the changes include that it is now possible to use perl's "strict" pragma in a natural way in plperl, and that perl's $a and $b variables now work as expected in sort routines, and that function compilation is significantly faster. Tim Bunce and Andrew Dunstan, with reviews from Alex Hunsaker and Alexey Klyukin. Security: CVE-2010-1169
2010-05-13 18:39:43 +02:00
*/
plperl: windows: Use Perl_setlocale on 5.28+, fixing compile failure. For older versions we need our own copy of perl's setlocale(), because it was not exposed (why we need the setlocale in the first place is explained in plperl_init_interp) . The copy stopped working in 5.28, as some of the used macros are not public anymore. But Perl_setlocale is available in 5.28, so use that. Author: Victor Wagner <vitus@wagner.pp.ru> Reviewed-By: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Discussion: https://postgr.es/m/20200501134711.08750c5f@antares.wagner.home Backpatch: all versions
2022-01-30 23:29:04 +01:00
#if defined(WIN32) && PERL_VERSION_LT(5, 28, 0)
Abandon the use of Perl's Safe.pm to enforce restrictions in plperl, as it is fundamentally insecure. Instead apply an opmask to the whole interpreter that imposes restrictions on unsafe operations. These restrictions are much harder to subvert than is Safe.pm, since there is no container to be broken out of. Backported to release 7.4. In releases 7.4, 8.0 and 8.1 this also includes the necessary backporting of the two interpreters model for plperl and plperlu adopted in release 8.2. In versions 8.0 and up, the use of Perl's POSIX module to undo its locale mangling on Windows has become insecure with these changes, so it is replaced by our own routine, which is also faster. Nice side effects of the changes include that it is now possible to use perl's "strict" pragma in a natural way in plperl, and that perl's $a and $b variables now work as expected in sort routines, and that function compilation is significantly faster. Tim Bunce and Andrew Dunstan, with reviews from Alex Hunsaker and Alexey Klyukin. Security: CVE-2010-1169
2010-05-13 18:39:43 +02:00
static char *
setlocale_perl(int category, char *locale)
{
PL/Perl portability fix: avoid including XSUB.h in plperl.c. In Perl builds that define PERL_IMPLICIT_SYS, XSUB.h defines macros that replace a whole lot of basic libc functions with Perl functions. We can't tolerate that in plperl.c; it breaks at least PG_TRY and probably other stuff. The core idea of this patch is to include XSUB.h only in the .xs files where it's really needed, and to move any code broken by PERL_IMPLICIT_SYS out of the .xs files and into plperl.c. The reason this hasn't been a problem before is that our build techniques did not result in PERL_IMPLICIT_SYS appearing as a #define in PL/Perl, even on some platforms where Perl thinks it is defined. That's about to change in order to fix a nasty portability issue, so we need this work to make the code safe for that. Rather unaccountably, the Perl people chose XSUB.h as the place to provide the versions of the aTHX/aTHX_ macros that are needed by code that's not explicitly aware of the MULTIPLICITY API conventions. Hence, just removing XSUB.h from plperl.c fails miserably. But we can work around that by defining PERL_NO_GET_CONTEXT (which would make the relevant stanza of XSUB.h a no-op anyway). As explained in perlguts.pod, that means we need to add a "dTHX" macro call in every C function that calls a Perl API function. In most of them we just add this at the top; but since the macro fetches the current Perl interpreter pointer, more care is needed in functions that switch the active interpreter. Lack of the macro is easily recognized since it results in bleats about "my_perl" not being defined. (A nice side benefit of this is that it significantly reduces the number of fetches of the current interpreter pointer. On my machine, plperl.so gets more than 10% smaller, and there's probably some performance win too. We could reduce the number of fetches still more by decorating the code with pTHX_/aTHX_ macros to pass the interpreter pointer around, as explained by perlguts.pod; but that's a task for another day.) Formatting note: pgindent seems happy to treat "dTHX;" as a declaration so long as it's the first thing after the left brace, as we'd already observed with respect to the similar macro "dSP;". If you try to put it later in a set of declarations, pgindent puts ugly extra space around it. Having removed XSUB.h from plperl.c, we need only move the support functions for spi_return_next and util_elog (both of which use PG_TRY) out of the .xs files and into plperl.c. This seems sufficient to avoid the known problems caused by PERL_IMPLICIT_SYS, although we could move more code if additional issues emerge. This will need to be back-patched, but first let's see what the buildfarm makes of it. Patch by me, with some help from Ashutosh Sharma Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
2017-07-28 18:25:43 +02:00
dTHX;
Abandon the use of Perl's Safe.pm to enforce restrictions in plperl, as it is fundamentally insecure. Instead apply an opmask to the whole interpreter that imposes restrictions on unsafe operations. These restrictions are much harder to subvert than is Safe.pm, since there is no container to be broken out of. Backported to release 7.4. In releases 7.4, 8.0 and 8.1 this also includes the necessary backporting of the two interpreters model for plperl and plperlu adopted in release 8.2. In versions 8.0 and up, the use of Perl's POSIX module to undo its locale mangling on Windows has become insecure with these changes, so it is replaced by our own routine, which is also faster. Nice side effects of the changes include that it is now possible to use perl's "strict" pragma in a natural way in plperl, and that perl's $a and $b variables now work as expected in sort routines, and that function compilation is significantly faster. Tim Bunce and Andrew Dunstan, with reviews from Alex Hunsaker and Alexey Klyukin. Security: CVE-2010-1169
2010-05-13 18:39:43 +02:00
char *RETVAL = setlocale(category, locale);
pgindent run for 9.0, second run
2010-07-06 21:19:02 +02:00
Abandon the use of Perl's Safe.pm to enforce restrictions in plperl, as it is fundamentally insecure. Instead apply an opmask to the whole interpreter that imposes restrictions on unsafe operations. These restrictions are much harder to subvert than is Safe.pm, since there is no container to be broken out of. Backported to release 7.4. In releases 7.4, 8.0 and 8.1 this also includes the necessary backporting of the two interpreters model for plperl and plperlu adopted in release 8.2. In versions 8.0 and up, the use of Perl's POSIX module to undo its locale mangling on Windows has become insecure with these changes, so it is replaced by our own routine, which is also faster. Nice side effects of the changes include that it is now possible to use perl's "strict" pragma in a natural way in plperl, and that perl's $a and $b variables now work as expected in sort routines, and that function compilation is significantly faster. Tim Bunce and Andrew Dunstan, with reviews from Alex Hunsaker and Alexey Klyukin. Security: CVE-2010-1169
2010-05-13 18:39:43 +02:00
if (RETVAL)
{
#ifdef USE_LOCALE_CTYPE
if (category == LC_CTYPE
#ifdef LC_ALL
|| category == LC_ALL
#endif
)
{
char *newctype;
pgindent run for 9.0, second run
2010-07-06 21:19:02 +02:00
Abandon the use of Perl's Safe.pm to enforce restrictions in plperl, as it is fundamentally insecure. Instead apply an opmask to the whole interpreter that imposes restrictions on unsafe operations. These restrictions are much harder to subvert than is Safe.pm, since there is no container to be broken out of. Backported to release 7.4. In releases 7.4, 8.0 and 8.1 this also includes the necessary backporting of the two interpreters model for plperl and plperlu adopted in release 8.2. In versions 8.0 and up, the use of Perl's POSIX module to undo its locale mangling on Windows has become insecure with these changes, so it is replaced by our own routine, which is also faster. Nice side effects of the changes include that it is now possible to use perl's "strict" pragma in a natural way in plperl, and that perl's $a and $b variables now work as expected in sort routines, and that function compilation is significantly faster. Tim Bunce and Andrew Dunstan, with reviews from Alex Hunsaker and Alexey Klyukin. Security: CVE-2010-1169
2010-05-13 18:39:43 +02:00
#ifdef LC_ALL
if (category == LC_ALL)
newctype = setlocale(LC_CTYPE, NULL);
else
#endif
newctype = RETVAL;
new_ctype(newctype);
}
#endif /* USE_LOCALE_CTYPE */
#ifdef USE_LOCALE_COLLATE
if (category == LC_COLLATE
#ifdef LC_ALL
|| category == LC_ALL
#endif
)
{
char *newcoll;
pgindent run for 9.0, second run
2010-07-06 21:19:02 +02:00
Abandon the use of Perl's Safe.pm to enforce restrictions in plperl, as it is fundamentally insecure. Instead apply an opmask to the whole interpreter that imposes restrictions on unsafe operations. These restrictions are much harder to subvert than is Safe.pm, since there is no container to be broken out of. Backported to release 7.4. In releases 7.4, 8.0 and 8.1 this also includes the necessary backporting of the two interpreters model for plperl and plperlu adopted in release 8.2. In versions 8.0 and up, the use of Perl's POSIX module to undo its locale mangling on Windows has become insecure with these changes, so it is replaced by our own routine, which is also faster. Nice side effects of the changes include that it is now possible to use perl's "strict" pragma in a natural way in plperl, and that perl's $a and $b variables now work as expected in sort routines, and that function compilation is significantly faster. Tim Bunce and Andrew Dunstan, with reviews from Alex Hunsaker and Alexey Klyukin. Security: CVE-2010-1169
2010-05-13 18:39:43 +02:00
#ifdef LC_ALL
if (category == LC_ALL)
newcoll = setlocale(LC_COLLATE, NULL);
else
#endif
newcoll = RETVAL;
new_collate(newcoll);
}
#endif /* USE_LOCALE_COLLATE */
#ifdef USE_LOCALE_NUMERIC
if (category == LC_NUMERIC
#ifdef LC_ALL
|| category == LC_ALL
#endif
)
{
char *newnum;
pgindent run for 9.0, second run
2010-07-06 21:19:02 +02:00
Abandon the use of Perl's Safe.pm to enforce restrictions in plperl, as it is fundamentally insecure. Instead apply an opmask to the whole interpreter that imposes restrictions on unsafe operations. These restrictions are much harder to subvert than is Safe.pm, since there is no container to be broken out of. Backported to release 7.4. In releases 7.4, 8.0 and 8.1 this also includes the necessary backporting of the two interpreters model for plperl and plperlu adopted in release 8.2. In versions 8.0 and up, the use of Perl's POSIX module to undo its locale mangling on Windows has become insecure with these changes, so it is replaced by our own routine, which is also faster. Nice side effects of the changes include that it is now possible to use perl's "strict" pragma in a natural way in plperl, and that perl's $a and $b variables now work as expected in sort routines, and that function compilation is significantly faster. Tim Bunce and Andrew Dunstan, with reviews from Alex Hunsaker and Alexey Klyukin. Security: CVE-2010-1169
2010-05-13 18:39:43 +02:00
#ifdef LC_ALL
if (category == LC_ALL)
newnum = setlocale(LC_NUMERIC, NULL);
else
#endif
newnum = RETVAL;
new_numeric(newnum);
}
#endif /* USE_LOCALE_NUMERIC */
}
return RETVAL;
}
plperl: windows: Use Perl_setlocale on 5.28+, fixing compile failure. For older versions we need our own copy of perl's setlocale(), because it was not exposed (why we need the setlocale in the first place is explained in plperl_init_interp) . The copy stopped working in 5.28, as some of the used macros are not public anymore. But Perl_setlocale is available in 5.28, so use that. Author: Victor Wagner <vitus@wagner.pp.ru> Reviewed-By: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Discussion: https://postgr.es/m/20200501134711.08750c5f@antares.wagner.home Backpatch: all versions
2022-01-30 23:29:04 +01:00
#endif /* defined(WIN32) && PERL_VERSION_LT(5, 28, 0) */