Re: Savepoint performance

My understanding of EDB's approach is that our prototype just
implicitly does a savepoint before each INSERT, UPDATE, or DELETE
statement inside of PLpgSQL. We then rollback to that savepoint if a
sql error occurs. I don 't believe our prelim approach changes any
transaction start/end semantics on the server side and it doesn't
change any PLpgSQL syntax either (although it does allow you to
optionally code commits &/or rollbacks inside stored procs).

Can anybody point me to a thread on the 7.3 disastrous experiment?

I personally think that doing commit or rollbacks inside stored
procedures is usually bad coding practice AND can be avoided... It's
a backward compatibility thing for non-ansi legacy stuff and this is
why I was previously guessing that the community wouldn't be
interested in this for PLpgSQL. Actually... does anybody know
offhand if the ansi standard for stored procs allows for explicit
transaction control inside of a stored procedure?

--Luss

On 7/27/06, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Denis Lussier" <denisl(at)enterprisedb(dot)com> writes:
> > Would the community be potentially interested in this feature if we created
> > a BSD Postgres patch of this feature for PLpgSQL (likely for 8.3)??
>
> Based on our rather disastrous experiment in 7.3, I'd say that fooling
> around with transaction start/end semantics on the server side is
> unlikely to fly ...
>
> regards, tom lane
>