From: | Aleksander Alekseev <aleksander(at)timescale(dot)com> |
---|---|
To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Cc: | kuznetsovam(at)altlinux(dot)org, nickel(at)altlinux(dot)org, egori(at)altlinux(dot)org |
Subject: | Re: PostgreSQL's approach to assertion usage: seeking best practices |
Date: | 2024-08-12 10:55:04 |
Message-ID: | CAJ7c6TMGHZNjjcQjikXSriC-mwhmJ_FmJvTts9az8HR9-tVXMw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi Alexander,
> As part of this effort, we conducted static analysis using Svace, which raised some questions regarding the use of the Assert() 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
From | Date | Subject | |
---|---|---|---|
Next Message | Ilia Evdokimov | 2024-08-12 10:59:24 | Re: Add support for (Var op Var) clause in extended MCV statistics |
Previous Message | Joel Jacobson | 2024-08-12 10:47:08 | Re: Optimize mul_var() for var1ndigits >= 8 |