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?

Keep in mind that nothing we come up with will be immune to abuse, and trying 
to solve what is fundamentally an education problem through technology rarely 
turns out well.

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.

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)
- 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
Jim C. Nasby, Data Architect                       j...@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to