Re: proposal: plpgsql - Assert statement

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: proposal: plpgsql - Assert statement
Дата
Msg-id CAFj8pRAd=rmv91zOqimvq2wYOUPd0yU8OqevzgYGh5KEphmS7Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: proposal: plpgsql - Assert statement  (Marko Tiikkaja <marko@joh.to>)
Ответы Re: proposal: plpgsql - Assert statement  (Marko Tiikkaja <marko@joh.to>)
Re: proposal: plpgsql - Assert statement  (Jan Wieck <jan@wi3ck.info>)
Список pgsql-hackers



2014-09-05 10:33 GMT+02:00 Marko Tiikkaja <marko@joh.to>:
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 [, ... ] ] ];

extension RAISE about ASSERT level has minimal new value

 

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?).

It is about semantic and conformity of proposed tools. Sure,  all can reduced to ASSERT(expr) .. but where is some benefit against function call

I am able to do without any change of language as plpgsql extension - there is no necessary to do any change for too thin proposal
 


.marko

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

Предыдущее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: Re: Escaping from blocked send() reprised.
Следующее
От: Marko Tiikkaja
Дата:
Сообщение: Re: proposal: plpgsql - Assert statement