PostgreSQL does not have a very smart exception handling model. Whenever the parser, planner/optimizer or executor decide that a statement cannot be processed any longer, the whole transaction gets aborted and the system jumps back into the main loop to get the next command from the client application.

It is possible to hook into the error mechanism to notice that this happens. But currently it is impossible to tell what really caused the abort (data type format error, floating-point error, parse error, etc.). And it is possible that the database server is in an inconsistent state at this point so returning to the upper executor or issuing more commands might corrupt the whole database.

Thus, the only thing PL/pgSQL currently does when it encounters an abort during execution of a function or trigger procedure is to add some fields to the message telling in which function and where (line number and type of statement) the error happened. The error always stops execution of the function.

2фффф ффффВ версии 8.0 в pl/pgsql добавили возможность перехвата исключений уже радует. Сенькс.

А как насчет updatable cursor ? Уже есть? А то в Unsupported Features для PostgreSQL 7.4beta4 Documentation видим:

- т.ч. не очень даже и понятно, накера тогда курсоры открывать. (опять же вразумительный поиск по условию в курсорах я не обнаружил - видимо самому предлагается поиск посредством полного скролирования осуществлять?). Это, впрочем, может статься и к лучшему - меньше соблазнов уклониться от лобового юзанья SQL.

Или я чего-то, как обычно, не догоняю?