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

From: Alex Hunsaker <badalex(at)gmail(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH]
Date: 2010-02-03 14:51:35
Message-ID: 34d269d41002030651g404dfbabxed031776e7559552@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Feb 3, 2010 at 06:41, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>
>
> Alex Hunsaker wrote:
>>>>>
>>>>> Well its already in.
>>>>>
>>>>
>>>> Well *that's* easily fixed.  I think it's a bad idea, because it's
>>>> unclear what you should put there and what the security implications
>>>> are.
>>>
>>>  I can't speak for its virtue, maybe Tim, Andrew?

> Regarding the naming of the params, I'm not keen to have more than one
> custom_variable_class for plperl. Within that, maybe we can bikeshed the
> names a bit. I don't have terribly strong feelings.

Hey! I don't think were quite to that nasty B word yet :) I would
argue that treating plperl and plperlu as the same language just
because it shares the same code is a mistake. But I hate the idea of
two custom_variable_classes for plperl(u) as well. Which is why I
quickly switched to plperl.on_plperl(u)_init. Any thoughts on those?
Again maybe people think the original names are fine... *shrug*.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2010-02-03 14:53:04 Re: Review of Writeable CTE Patch
Previous Message Andres Freund 2010-02-03 14:19:49 Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)