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

Re: Error handling in plperl and pltcl

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jan Wieck <JanWieck(at)Yahoo(dot)com>
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 03:43:10
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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

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.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Robert TreatDate: 2004-11-30 03:43:50
Subject: Re: bug fix request
Previous:From: Tom LaneDate: 2004-11-30 03:35:10
Subject: Re: multiline CSV fields

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