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  (Pavel Stehule <stehule@kix.fsv.cvut.cz>)
Re: plpgsql raise - parameters can (ToDo)  (Pavel Stehule <stehule@kix.fsv.cvut.cz>)
Re: plpgsql raise - parameters can be expressions  (Neil Conway <neilc@samurai.com>)
Список 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 по дате отправления:

Предыдущее
От: Atsushi Ogawa
Дата:
Сообщение: EUC_JP and SJIS conversion improvement
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: plpgsql raise - parameters can be expressions