Skip site navigation (1) Skip section navigation (2)

Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH]

From: Alex Hunsaker <badalex(at)gmail(dot)com>
To: Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH]
Date: 2010-02-03 03:42:21
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Sat, Jan 30, 2010 at 08:49, Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com> wrote:
> This is an update the fourth of the patches to be split out from the
> former 'plperl feature patch 1'.
> Changes in this patch:
> - Adds plperl.on_trusted_init and plperl.on_untrusted_init GUCs
>    on_trusted_init is PGC_USERSET, on_untrusted_init is PGC_SUSET

Im not a fan of the names (I think everyone gets trusted vs untrusted
confused). May I humbly suggest:
plperl.both_on_init <- this one is the one that throws the scheme off :(

>    SPI functions are not available when the code is run.

Hrm, we might want to stick why in the docs or as a comment somewhere.
I think this was the main concern?

* We call a plperl function for the first time in a session, causing to be loaded.  This happens in the context of a superuser
   calling a non-superuser security definer function, or perhaps vice
   versa.  Whose permissions apply to whatever the on_load code tries
   to do?  (Hint: every answer is wrong.)

> - select_perl_context() state management improved
>    An error during interpreter initialization will leave
>    the state (interp_state etc) unchanged.

This looked good.

> - The utf8fix code has been greatly simplified.

Yeah to the point that it makes me wonder if the old code had some
reason to spin up the FunctionCall stuff.  Do you happen to know?
Looks good to me otherwise.

The tests dont seem to pass :( this is from a make installcheck-world
test plperl_shared        ... FAILED
test plperl_init          ... FAILED

  SET plperl.on_trusted_init = '$_SHARED{on_init} = 42';
+ ERROR:  unrecognized configuration parameter "plperl.on_trusted_init"
  -- test the shared hash

If I throw a LOAD 'plperl'; at the top of those sql files it works...

The only quibble I have with the docs is:
+      If the code fails with an error it will abort the initialization and
+      propagate out to the calling query, causing the current transaction or
+      subtransaction to be aborted. Any changes within the perl won't be
+      undone.  If the <literal>plperl</> language is used again the
+      initialization will be repeated.

Instead of "Any changes within the perl won't be undone".  Maybe
"Changes to the perl interpreter will not be undone" ?

In response to


pgsql-hackers by date

Next:From: Robert HaasDate: 2010-02-03 03:46:13
Subject: Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH]
Previous:From: Tom LaneDate: 2010-02-03 02:40:29
Subject: Re: BUG #5304: psql using conninfo fails in connecting to the server

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group