Skip site navigation (1) Skip section navigation (2)

Re: TODO: Add a GUC to control whether BEGIN inside

From: Jim Nasby <decibel(at)decibel(dot)org>
To: Lukas Kahwe Smith <smith(at)pooteeweet(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: TODO: Add a GUC to control whether BEGIN inside
Date: 2007-01-03 15:40:38
Message-ID: A1794C03-B429-4C3E-8394-26FBDE88786C@decibel.org (view raw or flat)
Thread:
Lists: pgsql-hackers
On Jan 2, 2007, at 2:01 PM, Lukas Kahwe Smith wrote:
> Tom Lane wrote:
>> Lukas Kahwe Smith <smith(at)pooteeweet(dot)org> writes:
>>> Err, I think you misunderstood what I said. My implementation  
>>> uses SAVEPOINTs already. The point is having some API where you  
>>> do not have to care of you are already in a transaction or not.
>> It's not that hard, is it?
>> 	if (PQtransactionStatus(conn) == PQTRANS_IDLE)
>> 		PQexec(conn, "BEGIN");
>> 	else
>> 		PQexec(conn, "SAVEPOINT foo");
>
> Its not exactly convenient either, especially in the case of  
> modular code that may be developed by different people. Anyways,  
> like I said I have a solution in my framework to make life of  
> module developers easier. Obviously proper nested transactions  
> would be the ideal, but so it goes. I was just throwing this out  
> here when I saw Peter's comment.

+1. Right now it's not as big a deal since we don't allow transaction  
control inside functions, but if we ever get that ability it will  
become much more of a pain to write modular code that deals with  
savepoints/subtransactions.
--
Jim Nasby                                            jim(at)nasby(dot)net
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)



In response to

pgsql-hackers by date

Next:From: Greg Sabino MullaneDate: 2007-01-03 15:43:02
Subject: Re: Rare corruption of pg_class index
Previous:From: Simon RiggsDate: 2007-01-03 15:35:44
Subject: Re: [HACKERS] Patch to log usage of temporary files

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group