Re: A thread about SPs -- mentioning PostgreSQL
От | Fred Moyer |
---|---|
Тема | Re: A thread about SPs -- mentioning PostgreSQL |
Дата | |
Msg-id | 64237.69.17.66.125.1091329663.squirrel@mail.redhotpenguin.com обсуждение исходный текст |
Ответ на | A thread about SPs -- mentioning PostgreSQL (Devrim GUNDUZ <devrim@gunduz.org>) |
Ответы |
Re: A thread about SPs -- mentioning PostgreSQL
|
Список | 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
В списке pgsql-advocacy по дате отправления: