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
