Re: proposal: plpgsql - Assert statement

2014-09-05 11:17 GMT+02:00 Marko Tiikkaja <marko(at)joh(dot)to>:

> On 9/5/14 11:08 AM, Pavel Stehule wrote:
>
>> 2014-09-05 10:57 GMT+02:00 Marko Tiikkaja <marko(at)joh(dot)to>:
>>
>>> Oops. I meant to type ASSERT there, instead of RAISE. Does that make
>>> more sense?
>>>
>>
>> for me a basic limit is boolean_expr
>>
>
> I don't understand what you mean by this.
>
> 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 ..
>>
>
> #3 probably. Being able to satisfy #1 through PGXN is ridiculous. #2 and
> #4 would require at least hooking into PL/PgSQL, which might be possible,
> but it's intrusive and honestly feels fragile.
>
> But perhaps more to the point, why would that criticism apply to my
> suggestion, but not yours? Why don't we just reject any ASSERT syntax?
>
> and your proposed syntax
>> can be better processed on Postgres level than PLpgSQL level.
>>
>
> *shrug* Doing it in SQL would probably break more stuff. I'm trying to
> contain the damage. And arguably, this is mostly only useful in PL/PgSQL.
>
> 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.
>>
>
> Again, why does this criticism only apply to my suggestion and not yours?
>
>
There is one stronger difference - there is clean, what is targer of
assertation, because there is defined semantic.

When all is just any expression, there is nothing specified semantic

> ( 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.
>>
>
> You can do that anyway, you just need to work a bit harder. I don't see
> the problem, really.
>

bit harder, with possibility to false identification

>
>
> .marko
>