From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Marko Tiikkaja <marko(at)joh(dot)to> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: proposal: plpgsql - Assert statement |
Date: | 2014-09-05 09:08:48 |
Message-ID: | CAFj8pRB1dmD2Aam9dC+Nj7T-mZB_5VVvL4Y1ebXg0g=7TJ_tRQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2014-09-05 10:57 GMT+02:00 Marko Tiikkaja <marko(at)joh(dot)to>:
> 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?
>
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
>
From | Date | Subject | |
---|---|---|---|
Next Message | Marko Tiikkaja | 2014-09-05 09:17:13 | Re: proposal: plpgsql - Assert statement |
Previous Message | Craig Ringer | 2014-09-05 09:08:04 | Re: Allowing implicit 'text' -> xml|json|jsonb |