Re: Error handling in plperl and pltcl - Mailing list pgsql-hackers

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