Re: Add on_plperl_init and on_plperlu_init to plperl UPDATE 3 [PATCH]

From: Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Add on_plperl_init and on_plperlu_init to plperl UPDATE 3 [PATCH]
Date: 2010-02-08 13:44:16
Message-ID: 20100208134416.GA1618@timac.local
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Feb 07, 2010 at 08:25:33PM -0500, Andrew Dunstan wrote:
> Tim Bunce wrote:
> >This is the third update to the fourth of the patches to be split out
> >from the former 'plperl feature patch 1'.
> >
> >Changes in this patch:
> >
> >- Added plperl.on_plperl_init and plperl.on_plperlu_init GUCs
> > Both are PGC_SUSET
> > SPI functions are not available when the code is run.
> > Errors are detected and reported as ereport(ERROR, ...)
> > Corresponding documentation and tests for both.
> >
> >- Renamed plperl.on_perl_init to plperl.on_init
> >
> >- Improved state management of select_perl_context()
> > An error during interpreter initialization will leave
> > the state (interp_state etc) unchanged.
> >
> >- The utf8fix code has been greatly simplified.
> >
> >- More code comments re PGC_SUSET and no access to SPI functions.
>
>
> The docs on this patch need some cleaning up and expanding:
>
> * The possible insecurity of %_SHARED needs expanding.

I tried. I couldn't decide how to expand what Tom Lane suggested
(http://archives.postgresql.org/message-id/1344.1265223887@sss.pgh.pa.us)
without it turning into a sprawling security tutorial.

So, since his suggestion seemed complete enough (albeit fairly vague),
I just used it almost verbatim.

Also, the PL/Tcl docs don't mention the issue at all and the PL/Python
docs say only "The global dictionary GD is public data, available to all
Python functions within a session. Use with care."

The wording in the PL/Python docs seems better ("available to all ...
use with care"), so I've adopted the same kind of wording.

> * The docs still refer to plperl.on_untrusted_init

Oops. Thanks. Fixed.

> * plperl.on_plperl_init and plperl.on_plperlu_init can be documented
> together rather than repeating the same stuff almost word for word.

Ok. Done.

> * extra examples for these two, and an explanation of why one might
> want to use each of the three on*init settings would be good.

plperl.on_init has an example that seems fairly self-explantory.
I've added one to the on_plperl_init/on_plperlu_init section that
also explains how a superuser can use ALTER USER ... SET .... to set
a value for a non-superuser.

> I'll continue reviewing the patch, but these things at least need fixing.

I've an updated patch ready to go. I'll hold on to it for now.
Let me know if you have any more issues, or not.
Thanks.

Tim.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2010-02-08 13:47:02 Re: [COMMITTERS] pgsql: Create a "relation mapping" infrastructure to support changing
Previous Message Bruce Momjian 2010-02-08 13:34:06 Re: Hot standby documentation