Postgres Pro
Downloads
Home   >   mailing lists

Re: proposal: plpgsql - Assert statement - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: proposal: plpgsql - Assert statement
Date
Msg-id CAFj8pRBo10_pt_vinB_9HOq4Qhm_L94VRX-tbVENYKnGT_Wi=g@mail.gmail.com
Whole thread Raw
In response to Re: proposal: plpgsql - Assert statement  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: proposal: plpgsql - Assert statement
List pgsql-hackers
Tree view
Hi all

is there some agreement on this behave of ASSERT statement?

I would to assign last patch to next commitfest. 

Possible changes:

* I would to simplify a behave of evaluating of message expression - probably I disallow NULL there.
* GUC enable_asserts will be supported
* a assert exception should not be handled by PLpgSQL handler -- like CANCEL exception

Regards

Pavel



2014-12-14 19:54 GMT+01:00 Pavel Stehule <pavel.stehule@gmail.com>:


2014-12-14 18:57 GMT+01:00 Alvaro Herrera <alvherre@2ndquadrant.com>:
Pavel Stehule wrote:
> Hi
>
> any comments to last proposal and patch?

WTH is that pstrdup("hint is null") thing?  Debugging leftover?

No, only not well error message. I propose a syntax ASSERT boolean_expression [, text expression ] -- text expression is >>hint<< for assertion debugging

This text expression should not be null when it is used. I am not sure, what is well behave - so when assertions fails and text expression is null, then I use message "hint is null" as hint.

Regards

Pavel
 

--
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: New CF app: changing email sender
Next
From: Peter Geoghegan
Date:
Subject: Re: B-Tree support function number 3 (strxfrm() optimization)