Re: First feature patch for plperl - draft [PATCH]

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 00:53:47
Message-ID: FA0B1B61-15FE-4A47-BC8A-4E9AC6391C3A@kineticode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Dec 3, 2009, at 3:30 PM, Tim Bunce wrote:

> - New GUC plperl.on_perl_init='...perl...' for admin use.
> - New GUC plperl.on_trusted_init='...perl...' for plperl user use.
> - New GUC plperl.on_untrusted_init='...perl...' for plperlu user use.

Since there is no documentation yet, how do these work, exactly? Or should I just wait for the docs?

> - END blocks now run at backend exit (fixes bug #5066).
> - Stored procedure subs are now given names ($name__$oid).
> - More error checking and reporting.
> - Warnings no longer have an extra newline in the NOTICE text.
> - Various minor optimizations like pre-growing data structures.

Nice.

> I'm working on adding tests and documentation now, meanwhile I'd very
> much appreciate any feedback on the patch.
>
> Tim.
>
> p.s. Once this patch is complete I plan to work on patches that:
> - add quote_literal and quote_identifier functions in C.

I expect you can just use the C versions in PostgreSQL. They're in utils/builtins.h, along with quote_nullable(), which might also be useful to add.

> - generalize the Safe setup code to enable more control.
> - formalize namespace usage, moving things out of main::

Nice.

> - add a way to perform inter-sub calling (at least for simple cases).
> - possibly rewrite _plperl_to_pg_array in C.

Sounds great, Tim. I'm not really qualified to say anything about the C code, but I'd be happy to try it out once there are docs.

Best,

David

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David E. Wheeler 2009-12-04 01:40:09 Format Typmod?
Previous Message Jeff Davis 2009-12-04 00:42:06 Re: operator exclusion constraints