Re: proposal: plpgsql - Assert statement

From: Jim Nasby <jim(at)nasby(dot)net>
To: Jan Wieck <jan(at)wi3ck(dot)info>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Craig Ringer <craig(at)2ndquadrant(dot)com>, Marko Tiikkaja <marko(at)joh(dot)to>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal: plpgsql - Assert statement
Date: 2014-09-30 03:04:15
Message-ID: 542A1DAF.2000101@nasby.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2014-09-30 03:11:58 Re: Yet another abort-early plan disaster on 9.3
Previous Message Craig Ringer 2014-09-30 02:53:03 Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}