Re: Error handling in plperl and pltcl

Tom Lane wrote:

>On what evidence do you base that claim? It's true there are no
>existing Tcl or Perl functions that do error recovery from SPI
>operations, because it doesn't work in existing releases. That does
>not mean the demand is not there. We certainly got beat up on often
>enough about the lack of error trapping in plpgsql.
>
>
Lack of error trapping is one thing. To state that all error trapping
will do further accesses to the database is another altogether. I don't
have evidence for my claim since subtransactions hasn't been available
for that long but it's a pretty strong hunch. And the fact that all
current PostgreSQL functions out there works this way today should count
for something. Your suggestion will make the current code base
significantly slower, IMO for no reason.

>[ shrug... ] If you intend to design pljava that way I can't stop you.
>But I think it's a bogus design, because (a) it puts extra burden on the
>function author who's already got enough things to worry about
>
So it's an extra burden to create a savepoint, and commit/rollback
depending on the outcome? I'm sorry, but I have to disagree with that. I
think it's a powerful concept that developers will want to exploit.
Confusing try/catch with subtransactions is bogus and not an option for
me as I don't have the liberty of changing the language.

A strong argument for my design is that if I where to write similar code
in the client using a the JDBC driver, this is exactly what I'd have to
do. Why should code look any different just because I move it to the
backend?

So, I can't see the extra burden at all. This approach brings clarity,
no magic, and it enables ports of languages where SQL access has been
standardized to actually conform to that standard. That's most certainly
not bogus!

>(b) since you can't support arbitrary rollback patterns, you have to
>contort the semantics of Savepoint objects with restrictions that are
>both hard to design correctly and complicated to enforce.
>
>
On the contrary. It's very easy to enforce and PL/Java already does
this. The design is simple and clean. Savepoints are prohibited to live
beyond the invocation where they where created. If a savepoint is still
active when an invocation exits, the savepoint is released or rolled
back (depending on a GUC setting) and a warning is printed.

Here I have a couple of questions to you:
From your statement it sounds like you want to use the subtransactions
solely in a hidden mechanism and completely remove the ability to use
them from the function developer. Is that a correct interpretation?

Another question relating to a statement you made earlier. You claim
that an SPI call should check to see if it it is in a subtransaction and
only enter a new one if that's not the case. How do you in that case
intend to keep track of where the subtransaction started? I.e. how far
up in nesting levels do you need to jump before you reach the right place?

My argument is that whenever possible, you must let the creator of a
subtransaction have the responsibility to commit or roll it back.

>I don't believe you should do language design on the basis of avoiding
>a 25% overhead
>
I don't do language design. I'm adhering to the JDBC standard and I have
no way of enforcing magic code to be executed during try/catch.
Meanwhile, I really want PL/Java developers to have the ability to make
full use of savepoints.

>I got it down from 50% to 25%
>in one afternoon, doing nothing that seemed too risky for late beta.
>I think there's plenty more that can be done there when we have more
>time to work on it.
>
>
That's great. But even if you come down to 10% overhead it doesn't
really change anything.

Regards,
Thomas Hallgren