From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | fred(at)redhotpenguin(dot)com, "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 16:48:26 |
Message-ID: | 200408010948.26417.josh@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-advocacy |
Fred,
> 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.
Sure:
1) More efficient set operations: server-side stuff tends to do this better,
being closer to the database.
2) "Ironclad" business rules: by attaching an Constraint, Data-push Function,
Trigger or Rule to a table you make it impossible to break that Business
Rule. If the BR is in the mod_perl code, you're depending on your interface
developer's consistency, which can lead to mistakes.
3) "Virtual Tables": You can use set-returning functions to return rowsets
that would be difficult to get efficiently out of a view, such as queries
containing "dummy rows" or complex orderings.
> 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?
Once the new one is out of beta, yes. Your Testing Will Help (see the
PL/perlNG project).
--
Josh Berkus
Aglio Database Solutions
San Francisco
From | Date | Subject | |
---|---|---|---|
Next Message | Steve Bergman | 2004-08-01 16:52:37 | New to PostgreSQL |
Previous Message | Fred Moyer | 2004-08-01 03:07:43 | Re: A thread about SPs -- mentioning PostgreSQL |