| |||||||||||||
PostgreSQL 9.0 arrives with many new featuresPostgreSQL 9.0 arrives with many new featuresPosted Sep 22, 2010 11:59 UTC (Wed) by smurf (subscriber, #17840)In reply to: PostgreSQL 9.0 arrives with many new features by andresfreund Parent article: PostgreSQL 9.0 arrives with many new features
> So, the usage of stored procedures shouldn't matter...
..., except that said stored procedure affects something outside of PostgreSQL. I might actually want that to happen on the backup server too.
(Log in to post comments)
PostgreSQL 9.0 arrives with many new features Posted Sep 22, 2010 17:28 UTC (Wed) by captrb (subscriber, #2291) [Link]
That seems like a fragile way to do things. Rather than have stored procedures cause side effects outside the database, what if you published events to a listen/notify queue, then have external processes reading the queues and cause the external state change. Have multiple queues for multiple recipients. The master and backup server would read the events from the currently-active database, failing over like the rest of your applications.
Slave servers vs. Stored Procedures Posted Sep 22, 2010 18:55 UTC (Wed) by smurf (subscriber, #17840) [Link]
The operative word here is "queue". If I want to keep the database and the external world in sync, I can't queue my changes.
Of course, it's a trade-off, and has its own pitfalls (what if the stored procedure works on the master but fails on the slave?). But so has every other solution.
PostgreSQL 9.0 arrives with many new features Posted Oct 3, 2010 22:50 UTC (Sun) by Wol (guest, #4433) [Link]
If you're worried about that, shouldn't you be using transactions as well as stored procedures?
And in the databases I use, using a stored procedure like that would cause the application to fail - "side effects are not permitted in a transaction!".
Cheers,
|
|||||||||||||