Re: plpgsql raise - parameters can be expressions
От | Tom Lane |
---|---|
Тема | Re: plpgsql raise - parameters can be expressions |
Дата | |
Msg-id | 19378.1118671713@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: plpgsql raise - parameters can be expressions (Neil Conway <neilc@samurai.com>) |
Ответы |
Re: plpgsql raise - parameters can be expressions
Re: plpgsql raise - parameters can (ToDo) Re: plpgsql raise - parameters can be expressions |
Список | pgsql-patches |
Neil Conway <neilc@samurai.com> writes: > BTW, one regression is that an undefined variable in the RAISE list is > no longer a compile-time error: > ... > I don't see an easy way to get around this, though, and it's not too > concerning. Amusingly it does completely break the SQLSTATE and SQLERRM > tests we added a few days ago :) That doesn't bother me either, seeing that an undefined variable isn't detected at compile time anywhere else. However, fixing the SQLSTATE tests by removing them doesn't seem like a great solution ... > BTW, another easy improvement in this area is changing the RAISE format > string to allow it to be an expression, rather than only a string literal. I would sort of have expected this to get done at the same time. Actually, the reason I didn't do something about RAISE in 8.0 was that I thought we should reconsider the whole design of the statement: it desperately needs to be fixed so that you can specify the SQLSTATE to be thrown, and so that you can re-throw the same exception you caught. (Note that SQLERRM is not really a solution to that: you might think something like "RAISE EXCEPTION SQLSTATE, '%', SQLERRM" would do, but it loses information, namely all the auxiliary fields.) Ideas? regards, tom lane
В списке pgsql-patches по дате отправления: