Re: proposal: plpgsql - Assert statement
От | Marko Tiikkaja |
---|---|
Тема | Re: proposal: plpgsql - Assert statement |
Дата | |
Msg-id | 5409754C.1010909@joh.to обсуждение исходный текст |
Ответ на | Re: proposal: plpgsql - Assert statement (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: proposal: plpgsql - Assert statement
|
Список | pgsql-hackers |
On 9/5/14 10:09 AM, Pavel Stehule wrote: >> I think this could still be parsed correctly, though I'm not 100% sure on >> that: >> >> ASSERT WARNING (EXISTS(SELECT ..)), 'data are there'; >> > > PLpgSQL uses a ';' or some plpgsql keyword as SQL statement delimiter. It > reason why RETURN QUERY ... ';' So in this case can practical to place SQL > statement on the end of plpgsql statement. *shrug* There are lots of cases where a comma is used as well, e.g. RAISE NOTICE '..', <expr>, <expr>; > parenthesis are not practical, because it is hard to identify bug .. I don't see why. The PL/PgSQL SQL parser goes to great lengths to identify unmatched parenthesis. But the parens probably aren't necessary in the first place; you could just omit them and keep parsing until the next comma AFAICT. So the syntax would be: RAISE [ NOTICE | WARNING | EXCEPTION/ASSERT/WHATEVER ] boolean_expr [, error_message [, error_message_param [, ... ] ] ]; > A simplicity of integration SQL and PLpgSQL is in using "smart" keywords - > It is more verbose, and it allow to well diagnostics I disagree. The new keywords provide nothing of value here. They even encourage the use of quirky syntax in *exchange* for verbosity ("IS NOT NULL pk"? really?). .marko
В списке pgsql-hackers по дате отправления: