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
>

Reply via email to