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

Re: Error handling in plperl and pltcl

From: Jan Wieck <JanWieck(at)Yahoo(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Thomas Hallgren <thhal(at)mailblocks(dot)com>,pgsql-hackers(at)postgresql(dot)org
Subject: Re: Error handling in plperl and pltcl
Date: 2004-11-30 04:00:05
Message-ID: 41ABF045.5090508@Yahoo.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On 11/29/2004 10:43 PM, Tom Lane wrote:

> Jan Wieck <JanWieck(at)Yahoo(dot)com> writes:
>> I don't agree that the right cure is to execute each and every statement 
>> itself as a subtransaction. What we ought to do is to define a wrapper 
>> for the catch Tcl command, that creates a subtransaction and executes 
>> the code within during that.
> 
> What I would like to do is provide a catch-like Tcl command that defines
> a subtransaction, and then optimize the SPI commands so that they don't
> create their own sub-subtransaction if they can see they are directly
> within the subtransaction command.  But when they aren't, they need to
> define their own subtransactions so that the error semantics are
> reasonable.  I think what you're saying is that a catch command should
> be exactly equivalent to a subtransaction, but I'm unconvinced --- a
> catch might be used around some Tcl operations that don't touch the
> database, in which case the subtransaction overhead would be a serious
> waste.

That is right. What the catch replacement command should do is to 
establish some sort of "catch-level", run the script inside the catch 
block. The first spi operation inside of that block causes a 
subtransaction to be created and remembered in that catch-level. At the 
end - i.e. when that block of commands finishes, the subtransaction is 
committed or rolled back and nothing done if the command block didn't 
hit any spi statement.

> 
> The real point here is that omitting the per-command subtransaction
> ought to be a hidden optimization, not something that intrudes to the
> point of having unclean semantics when we can't do it.

We could treat the entire function call as one subtransaction in the 
first place. Then create more sub-subtransactions as catch blocks appear.


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck(at)Yahoo(dot)com #

In response to

pgsql-hackers by date

Next:From: Robert TreatDate: 2004-11-30 04:01:04
Subject: Re: Aubit 4GL for postgresql
Previous:From: Bruce MomjianDate: 2004-11-30 03:53:35
Subject: Re: multiline CSV fields

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