Re: PostgreSQL's approach to assertion usage: seeking best practices - Mailing list pgsql-hackers

From Aleksander Alekseev
Subject Re: PostgreSQL's approach to assertion usage: seeking best practices
Date
Msg-id CAJ7c6TMGHZNjjcQjikXSriC-mwhmJ_FmJvTts9az8HR9-tVXMw@mail.gmail.com
Whole thread Raw
In response to PostgreSQL's approach to assertion usage: seeking best practices  (Alexander Kuznetsov <kuznetsovam@altlinux.org>)
List pgsql-hackers
Hi Alexander,

> As part of this effort, we conducted static analysis using Svace, which raised some questions regarding the use of
theAssert() function.
 
> We were unable to find clear answers in the documentation or previous discussions and would greatly appreciate your
insights,
> as these will influence how we approach future patch submissions:
>
> 1. General purpose of Assert() function:
> - Is the primary purpose of the Assert() function to:
>      - Inform developers of the assumptions made in the code,
>      - Facilitate testing of new builds with assertions enabled,
>      - Accelerate development by temporarily placing assertions where defensive code may later be required,
>      - Or does it serve some other purpose?
>
> 2. Assertions and defensive code:
> [...]
>
> 3. Approach to fixing flaws:
> [...]

Assert() describes an invariant - e.g. x should never be NULL here.
It's present only in the debug builds. It has two purposes. 1. Check
the invariants during the execution of the tests and usage of a debug
build. 2. Serve as a description of the invariant for the developers.
Adding Asserts() is usually a good idea unless the invariant is too
expensive to check and/or complicated to read/understand.


--
Best regards,
Aleksander Alekseev



pgsql-hackers by date:

Previous
From: "Joel Jacobson"
Date:
Subject: Re: Optimize mul_var() for var1ndigits >= 8
Next
From: Ilia Evdokimov
Date:
Subject: Re: Add support for (Var op Var) clause in extended MCV statistics