Re: proposal: plpgsql - Assert statement

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



2014-09-05 10:57 GMT+02:00 Marko Tiikkaja <marko@joh.to>:
On 9/5/14 10:40 AM, Pavel Stehule wrote:
2014-09-05 10:33 GMT+02:00 Marko Tiikkaja <marko@joh.to>:
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

Oops.  I meant to type ASSERT there, instead of RAISE.  Does that make more sense?

for me a basic limit is boolean_expr
 

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 see several benefits:

  1) Standard syntax, available anywhere
  2) Since the RAISE EXCEPTION happens at the caller's site, we can provide information not available to an ordinary function, such as the values of the parameters passed to it
  3) We can make the exception uncatchable
  4) ASSERTs can be easily disabled (if we choose to allow that), even per-function

All points can be solved  by extension on PGXN .. and your proposed syntax can be better processed on Postgres level than PLpgSQL level.
 

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

What *exactly* about my proposal is "too thin"?  What does your thing do that mine doesn't?  If you're saying your suggestion allows us to give a better error message, I disagree:

"Too thin" it means so there is not possibility to extensibility, possibility to define dafaults, possibility to use it for static analyse.
 


  ( ROW_COUNT ( = | <> ) ( 1 | 0 ) |

I've already addressed this: we can print the parameters and their values automatically, so printing the row count here doesn't give any additional value.

In this case, I can use a plpgsql parser for static analyse - I can do warning, if related query has not filter PK and similar.
 

  ( QUERY some query should not be empty ) |

With this definition, absolutely zero value over ASSERT EXISTS(..);

  ( CHECK some expression should be true )

No additional value; it's either NULL, FALSE or TRUE and both syntaxes can display what the expression evaluated to.

  ( IS NOT NULL expression should not be null )

It's either NULL or it isn't.  No additional value.



.marko

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

Предыдущее
От: Craig Ringer
Дата:
Сообщение: Re: Allowing implicit 'text' -> xml|json|jsonb
Следующее
От: Marko Tiikkaja
Дата:
Сообщение: Re: proposal: plpgsql - Assert statement