possible bug in exception handling code? (postgres8.0beta)

Поиск
Список
Период
Сортировка
От Paramveer.Singh@trilogy.com
Тема possible bug in exception handling code? (postgres8.0beta)
Дата
Msg-id OF9E61394E.3AA12547-ONE5256EF5.002EEA5D@trilogy.com
обсуждение исходный текст
Ответы Re: possible bug in exception handling code? (postgres8.0beta)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-general
Hi all!
I was looking into the postgres8.0 code for exception handling,
and it seems that the grammer treats an exception condition as opt_lblname.
This means that I can pass any arbitrary string as an exception condition.
This also means that implementation of user defined exceptions would be in
trouble.

Note that the execution would not be affected(for now, i.e. without user
defined exceptions), it's just a compiler vulnerability.

example:

declare
      a int;
begin
      return 1;
exception
      when a OR any_random_string OR DIVISION_BY_ZERO then
            return 0;
end;

would compile, when in fact it should not. (or am I totally wrong here?)
pl_exec.c has a exception label map which is used at execution, when the
exception actually happens.
Wouldn't it be preferable to use it at compile time?

**************

Also, I noticed that for

begin
      valid_stmt_1;
      valid_stmt_2;
      zero_divide_exception_causing_stmt;
exception
      when DIVISION_BY_ZERO then
            return safely;
end;

valid_stmt_1 and 2 are rolled back.
This happens because whenever execution goes into the catch block,
the staments for that level are rolled back before searching for
exceptions.
Shouldn't it be the other way around? as in, searching for a handler, and
rolling the subtransaction back only if no handler is found?

thanks
paraM



В списке pgsql-general по дате отправления:

Предыдущее
От: Fuchs Clemens
Дата:
Сообщение: Pass parameters to SQL script
Следующее
От: "Andrew Hall"
Дата:
Сообщение: Stored Procedures woes