Re: proposal: plpgsql - Assert statement

2014-09-30 10:04 GMT+07:00 Jim Nasby <jim@nasby.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