Re: proposal: plpgsql - Assert statement
| От | Ali Akbar |
|---|---|
| Тема | Re: proposal: plpgsql - Assert statement |
| Дата | |
| Msg-id | CACQjQLo=u386B_bQx2xMX1vhzUBscLWY=kRz3bj+XEipFLghAw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: proposal: plpgsql - Assert statement (Jim Nasby <jim@nasby.net>) |
| Ответы |
Re: proposal: plpgsql - Assert statement
|
| Список | pgsql-hackers |
2014-09-30 10:04 GMT+07:00 Jim Nasby <jim@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
В списке pgsql-hackers по дате отправления: