On Tue, 2013-11-19 at 10:40 -0500, Robert Haas wrote: > I think the goal was to get to RAISE ASSERT > WHEN ...; then, if assertions are off, you do nothing; if they're on, > you error. IF condition THEN RAISE..." isn't a suitable surrogate in > that case because you incur the overhead of testing the condition > regardless.
So if I do RAISE ASSERT WHEN condition and assertions are off, then condition wouldn't even be evaluated? But what about RAISE NOTICE WHEN, when log_min_messages is error? What about the side effects of the format string? This is all just getting too weird.
I don't see anything wrong with considering a separate ASSERT command with its own semantics, like in many other programming languages.
My objection against ASSERT command was one - it was too simply (against to cost of possible collision from introduction new (wide used) keyword.
I can live with ASSERT statement - but I expect as minimum a possibility to specify level (failure, tracing, ...) and specify a message related to assert. Assert with only expression is not enough.