2014-10-15 11:57 GMT+02:00 Ali Akbar <the.ap...@gmail.com>: > 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). >
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 >
