From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Joshua Tolley <eggyknap(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: plperl and inline functions -- first draft |
Date: | 2009-11-13 15:05:58 |
Message-ID: | 4AFD75D6.40309@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Joshua Tolley wrote:
> 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?
>
>
Loading both plperl and plperlu could have problems, as there are some
platforms where we can't use them both in the same session, due to some
perl oddities. We would need to test this on one such - I don't recall
which they are.
"Config" might be a better choice than "Data::Dumper". The Perl team or
some packagers could drop Data::Dumper some day, but they aren't likely
to drop Config.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2009-11-13 15:12:55 | Re: next CommitFest |
Previous Message | Tom Lane | 2009-11-13 15:01:59 | Re: Aggregate ORDER BY patch |