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