From: | "David E(dot) Wheeler" <david(at)kineticode(dot)com> |
---|---|
To: | Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: First feature patch for plperl - draft [PATCH] |
Date: | 2009-12-04 17:40:08 |
Message-ID: | 004BC628-506A-489A-B0D9-820C15D40852@kineticode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Dec 4, 2009, at 3:18 AM, Tim Bunce wrote:
> The perl code in plperl.on_perl_init gets eval'd as soon as an
> interpreter is created. That could be at server startup if
> shared_preload_libraries is used. plperl.on_perl_init can only be set by
> an admin (PGC_SUSET).
Are multiline GUCs allowed in the postgresql.conf file?
> The perl code in plperl.on_trusted_init gets eval'd when an interpreter
> is initialized into trusted mode, e.g., used for the plperl language.
> The perl code is eval'd inside the Safe compartment.
> plperl.on_trusted_init can be set by users but it's only useful if set
> before the plperl interpreter is first used.
So immediately after connecting would be the place to make sure you do it, IOW.
> plperl.on_untrusted_init acts like plperl.on_trusted_init but for
> plperlu code.
>
> So, if all three were set then, before any perl stored procedure or DO
> block is executed, the interpreter would have executed either
> on_perl_init and then on_trusted_init (for plperl), or on_perl_init and
> then on_untrusted_init (for plperlu).
Awesome, thanks! This is really a great feature.
>> along with quote_nullable(), which might also be useful to add.
>
> I was planning to build that behaviour into quote_literal since it fits
> naturally into perl's idea of undef and mirrors DBI's quote() method.
> So:
> quote_literal(undef) => "NULL"
> quote_literal('foo') => "'foo'"
Is there an existing `quote_literal()` in PL/Perl? If so, you might not want to change its behavior.
>>> - generalize the Safe setup code to enable more control.
>
> Specifically control what gets loaded into the Compartment, what gets
> shared with it (e.g. sharing *a & *b as a workaround for the sort bug),
> and what class to use for Safe (to enable deeper changes if desired via
> subclassing). Naturally all this is only possible for admin (via
> plperl.on_perl_init).
Sounds good.
>>> - formalize namespace usage, moving things out of main::
>>
>> Nice.
>>
>>> - add a way to perform inter-sub calling (at least for simple cases).
>
> My current plan here is to use an SP::AUTOLOAD to handle loading and
> dispatching. So calling SP::some_random_procedure(...) will trigger
> SP::AUTOLOAD to try to resolve "some_random_procedure" to a particular
> stored procedure. There are three tricky parts: handling polymorphism (at
> least "well enough"), making autoloading of stored procedures work
> inside Safe, making it fast. I think I have reasonable approaches for
> those but I won't know for sure till I work on it.
I'm wondering if there might be some way to use some sort of attributes to identify data types passed to a PL/Perl function called from another PL/Perl function. Maybe some other functions that identify types, in the case of ambiguities?
foo(int(1), text('bar'));
? Kind of ugly, but perhaps only to be used if there are ambiguities? Not sure it's a great idea, mind. Just thinking out loud (so to speak).
Best,
David
From | Date | Subject | |
---|---|---|---|
Next Message | Kern Sibbald | 2009-12-04 17:46:37 | Re: Catastrophic changes to PostgreSQL 8.4 |
Previous Message | Andres Freund | 2009-12-04 17:27:44 | Re: PostgreSQL Release Support Policy |