<div dir="ltr"><br /><div class="gmail_extra"><br /><br /><div class="gmail_quote">2013/11/27 Peter Eisentraut <span
dir="ltr"><<ahref="mailto:peter_e@gmx.net" target="_blank">peter_e@gmx.net</a>></span><br /><blockquote
class="gmail_quote"style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Tue,
2013-11-19at 10:40 -0500, Robert Haas wrote:<br /> > I think the goal was to get to RAISE ASSERT<br /> > WHEN
...;then, if assertions are off, you do nothing; if they're on,<br /> > you error. IF condition THEN RAISE..."
isn'ta suitable surrogate in<br /> > that case because you incur the overhead of testing the condition<br /> >
regardless.<br/><br /></div>So if I do RAISE ASSERT WHEN condition and assertions are off, then<br /> condition
wouldn'teven be evaluated? But what about RAISE NOTICE WHEN,<br /> when log_min_messages is error? What about the
sideeffects of the<br /> format string? This is all just getting too weird.<br /><br /> I don't see anything wrong
withconsidering a separate ASSERT command<br /> with its own semantics, like in many other programming languages.<br
/><br/><br /></blockquote></div>My objection against ASSERT command was one - it was too simply (against to cost of
possiblecollision from introduction new (wide used) keyword.<br /><br /></div><div class="gmail_extra">I can live with
ASSERTstatement - but I expect as minimum a possibility to specify level (failure, tracing, ...) and specify a message
relatedto assert. Assert with only expression is not enough.<br /><br /></div><div class="gmail_extra">Regards<br /><br
/>Pavel<br /></div></div>
