[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgresql-general
Subject:    Re: [HACKERS] proposal: plpgsql - Assert statement
From:       Jim Nasby <jim () nasby ! net>
Date:       2014-09-30 3:04:15
Message-ID: 542A1DAF.2000101 () nasby ! net
[Download RAW message or body]

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                       jim@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:
http://www.postgresql.org/mailpref/pgsql-hackers


[prev in list] [next in list] [prev in thread] [next in thread]