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