From: | "Fred Moyer" <fred(at)redhotpenguin(dot)com> |
---|---|
To: | "Devrim GUNDUZ" <devrim(at)gunduz(dot)org> |
Cc: | pgsql-advocacy(at)postgresql(dot)org |
Subject: | Re: A thread about SPs -- mentioning PostgreSQL |
Date: | 2004-08-01 03:07:43 |
Message-ID: | 64237.69.17.66.125.1091329663.squirrel@mail.redhotpenguin.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-advocacy |
> There is a new thread at /. "Stored Procedures - Good or Bad?", and it
> mentions about PostgreSQL among enterprise databases:
>
>http://ask.slashdot.org/askslashdot/04/07/30/2324206.shtml?tid=198&tid=156&tid=4&tid=1&tid=8&tid=218
>
So being both a programmer and dba, with a database like PostgreSQL which
has procedural languages in several different flavors, I am wondering what
else besides robust transactions PostgreSQL stored procedures provides?
(that in itself is enough for me) Achieving transactions on the
application side has it's caveats, which is why I am keen on using
PostgreSQL's transactional API for data (read object) persistence.
I spend the bulk of my time right now coding mod_perl, so I ask you
pgsql-advocacy list, is pl/perl functionally equivalent to pl/pgsql? If I
can move my persistence layer to PostgreSQL, with pl/perl taking care of
the under-the-persistence-layer-api-work, I would love to do so. Perl is
great for manipulating data structures - PostgreSQL is great for storing
them. But I need some solid arguments; I am easy to sell on the idea but
my colleagues are somewhat more discerning :)
- Fred
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2004-08-01 16:48:26 | Re: A thread about SPs -- mentioning PostgreSQL |
Previous Message | Scott Marlowe | 2004-07-31 08:27:45 | Re: A thread about SPs -- mentioning PostgreSQL |