On 9/5/14 11:08 AM, Pavel Stehule wrote:
> 2014-09-05 10:57 GMT+02:00 Marko Tiikkaja <marko@joh.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?
>> ( 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.
.marko
