Re: proposal: plpgsql - Assert statement

From: Marko Tiikkaja <marko(at)joh(dot)to>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal: plpgsql - Assert statement
Date: 2014-09-05 08:57:07
Message-ID: 54097AE3.5000406@joh.to
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 9/5/14 10:40 AM, Pavel Stehule wrote:
> 2014-09-05 10:33 GMT+02:00 Marko Tiikkaja <marko(at)joh(dot)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?

>> 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

> 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:

( 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.

( 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Marko Tiikkaja 2014-09-05 09:04:31 Re: Allowing implicit 'text' -> xml|json|jsonb
Previous Message Pavel Stehule 2014-09-05 08:40:32 Re: proposal: plpgsql - Assert statement