in reply to Perl, PostgreSQL, and Where Things Are Done

My main question would be "how stable is PL/Perl?" You need to be pretty sure something like is solid before you start using it in a major way on your database server.

However, assuming it is solid at this point, the biggest downside seems to be the limited level of perl support. I don't see any support for running the debugger or using modules. That takes away a lot of the value of using perl.

Clustering could be a downside too. When you run your code in a separate server like mod_perl, you can spread your code across 20 machines very simply, and harness the power of cheap hrdware. Having twenty databases in a cluster is a lot harder, although it is possible for some situations where a small amount of replication lag is not an issue.

Even with these downsides, it still might be the perfect for certain kinds of database problems that normally require a lot of data to be transferred.

  • Comment on Re: Perl, PostgreSQL, and Where Things Are Done

Replies are listed 'Best First'.
Re^2: Perl, PostgreSQL, and Where Things Are Done
by grinder (Bishop) on Jan 20, 2005 at 08:47 UTC
    My main question would be "how stable is PL/Perl?"

    It's been around for a while, if that's any guide to stability. Just for the record, Perl stored procedures for Pg was added by Mark Hollomon in 7.0, which was released 2000-05-08. That means its coming up to five years old.

    See also http://www.postgresql.org/docs/8.0/static/plperl-trusted.html for a bit more on using modules.

    - another intruder with the mooring in the heart of the Perl

[reply]

In Section Meditations