Re: proposal: plpgsql - Assert statement

2014-10-15 11:57 GMT+02:00 Ali Akbar <the(dot)apaan(at)gmail(dot)com>:

> 2014-09-30 10:04 GMT+07:00 Jim Nasby <jim(at)nasby(dot)net>:
>
>> On 9/17/14, 7:40 PM, Jan Wieck wrote:
>>
>>> Exactly. Doing something like
>>>
>>> ASSERT (select count(*) from foo
>>> where fk not in (select pk from bar)) = 0;
>>>
>>> is a perfectly fine, arbitrary boolean expression. It will probably work
>>> well in a development environment too. And I am very sure that it will not
>>> scale well once that code gets deployed. And I know how DBAs react to the
>>> guaranteed following performance problem. They will disable ALL assert ...
>>> or was there some sort of assert class system proposed that I missed?
>>>
>>
> Actually, compared with for example Java or C, in production systems,
> usually all asserts are disabled for performance (in java removed by JIT,
> in C we define NDEBUG).
>

This argument should not be too valid for plpgsql - possible bottlenecks
are in SQL execution (or should be)

>
>
>> We're also putting too much weight on the term "assert" here. C-style
>> asserts are generally not nearly as useful in a database as general
>> sanity-checking or error handling, especially if you're trying to use the
>> database to enforce data sanity.
>>
>
> +1.
> without any query capability, assert will become much less useful. If we
> cannot query in assert, we will code:
>
> -- perform some query
> ASSERT WHEN some_check_on_query_result;
>
> .. and disabling the query in production system will become another
> trouble.
>
> My wish-list for "asserts" is:
>>
>> - Works at a SQL level
>> - Unique/clear way to identify asserts (so you're not guessing where the
>> assert came from)
>>
> +1
>
>
>> - Allows for over-riding individual asserts (so if you need to do
>> something you're "not supposed to do" you still have the protection of all
>> other asserts)
>> - Less verbose than IF THEN RAISE END IF
>>
> +1
>
> --
> Ali Akbar
>