To: Christian Storm <christian.storm@gmail.com>
cc: "Jim C. Nasby" <jnasby@pervasive.com>, Josh Berkus <josh@agliodbs.com>,
	pgsql-performance@postgresql.org, PFC <lists@peufeu.com>
Subject: Re: pgmemcache 
In-reply-to: <4D23826E-7325-4946-B79A-80E321E0E497@gmail.com> 
References: <1144135482.063425.33380@z34g2000cwc.googlegroups.com>
	<20060411225515.GZ49405@pervasive.com> <op.s7vvyggtcigqcu@apollo13>
	<200604121603.43986.josh@agliodbs.com>
	<20060413001024.GP49405@pervasive.com>
	<6236.1144888514@sss.pgh.pa.us>
	<4D23826E-7325-4946-B79A-80E321E0E497@gmail.com>
Comments: In-reply-to Christian Storm <christian.storm@gmail.com>
	message dated "Thu, 13 Apr 2006 10:29:28 -0700"
Date: Thu, 13 Apr 2006 13:38:00 -0400
Message-ID: <26792.1144949880@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Christian Storm <christian.storm@gmail.com> writes:
> Not sure if I follow why this is a problem.  Seems like it would be  
> beneficial to have both BEFORE and AFTER COMMIT triggers.
> With the BEFORE COMMIT trigger you would have the ability to 'un- 
> commit' (rollback) the transaction.  With
> the AFTER COMMIT trigger you wouldn't have that option because the  
> commit has already been successful.  However,
> with an AFTER COMMIT you would be able to trigger other downstream  
> events that rely on a transaction successfully committing.

An AFTER COMMIT trigger would have to be in a separate transaction.
What happens if there's more than one, and one of them fails?  Even
more to the point, if it's a separate transaction, don't you have
to fire all these triggers again when you commit that transaction?
The idea seems circular.

			regards, tom lane