Re: proposal: plpgsql - Assert statement

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).

> 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