Re: Error handling in plperl and pltcl
От
James William Pye
Тема
Re: Error handling in plperl and pltcl
Дата
Msg-id
1101144085.32981.53.camel@localhost
Ответ на
Re: Error handling in plperl and pltcl (Tom Lane)
Список
Дерево обсуждения
Error handling in plperl and pltcl Tom Lane <tgl@sss.pgh.pa.us>
Re: Error handling in plperl and pltcl James William Pye <flaw@rhid.com>
Re: Error handling in plperl and pltcl Tom Lane <tgl@sss.pgh.pa.us>
Re: Error handling in plperl and pltcl James William Pye <flaw@rhid.com>
Re: Error handling in plperl and pltcl Thomas Hallgren <thhal@mailblocks.com>
Re: Error handling in plperl and pltcl Thomas Hallgren <thhal@mailblocks.com>
Re: Error handling in plperl and pltcl Andrew Dunstan <andrew@dunslane.net>
Re: Error handling in plperl and pltcl Tom Lane <tgl@sss.pgh.pa.us>
Re: Error handling in plperl and pltcl Tom Lane <tgl@sss.pgh.pa.us>
On Sat, 2004-11-20 at 16:39 -0500, Tom Lane wrote: > You're right. You can *not* expose those as user-callable operations in > a PL language. Consider for example what will happen if the user tries > to roll back to a savepoint that was established outside your function > call, or tries to exit the function while still inside a local > savepoint. You have to enforce strict nesting of functions and > subtransactions; therefore it's a lot easier to present an API that > looks like an exception-block construct (per plpgsql), or that just > hides the whole deal in the SPI calling interface (as I'm proposing for > plperl/pltcl). Hrm, what about a savepoint scoping facility that would be wrapped around calls to [volatile?] functions to explicitly enforce these regulations? [...Poking around the archives a bit...] [Or do I mean savepoint levels?]: http://archives.postgresql.org/pgsql-hackers/2004-07/msg00505.php http://archives.postgresql.org/pgsql-hackers/2004-09/msg00569.php -- Regards, James William Pye
В списке pgsql-hackers по дате отправления