Re: plperl and inline functions -- first draft - Mailing list pgsql-hackers

From Joshua Tolley
Subject Re: plperl and inline functions -- first draft
Date
Msg-id 20091109160742.GG4974@eddie
Whole thread Raw
In response to Re: plperl and inline functions -- first draft  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: plperl and inline functions -- first draft
Re: plperl and inline functions -- first draft
Re: plperl and inline functions -- first draft
List pgsql-hackers
On Fri, Nov 06, 2009 at 09:53:20PM -0500, Andrew Dunstan wrote:
>
>
> Joshua Tolley wrote:
>>  I looked through the
>> regression tests and didn't find any that used plperl -- should we add one for
>> this (or for this and all kinds of other stuff)? Is there some way to make
>> running the regression test conditional on having built --with-perl in the
>> first place?
>>
>>
>
> Look in src/pl/plperl/{sql,expected}

Ok, updated patch attached. As far as I know, this completes all outstanding
issues:

1) weird comment in plperl.c is corrected and formatted decently
2) plperlu vs. plperl actually works (thanks again, Andrew)
3) docs included
4) regression tests included

Some items of note include that this makes the regression tests add not only
plperl to the test database but also plperlu, which is a new thing. I can't
see why this might cause problems, but thought I'd mention it. The tests
specifically try to verify that plperl doesn't allow 'use Data::Dumper', and
plperlu does. Since Data::Dumper is part of perl core, that seemed safe, but
it is another dependency, and perhaps we don't want to do that. If not, is
there some other useful way of testing plperlu vs. plperl, and does it really
matter?

--
Joshua Tolley / eggyknap
End Point Corporation
http://www.endpoint.com

Attachment

pgsql-hackers by date:

Previous
From: Sonu
Date:
Subject: Re: Specific names for plpgsql variable-resolution control options?
Next
From: Tom Lane
Date:
Subject: Re: drop tablespace error: invalid argument