Re: Assert for frontend programs?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Assert for frontend programs?
Date: 2012-12-14 20:48:29
Message-ID: 6295.1355518109@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> I noticed, BTW, that there are one or two places in backend code that
> seem to call plain assert unconditionally, notably src/port/open.c,
> src/backend/utils/adt/inet_net_pton.c and some contrib modules. That
> seems undesirable. Should we need to look at turning these into Assert
> calls?

Yeah, possibly. The inet_net_pton.c case is surely because it was that
way in the BIND code we borrowed; perhaps the others are the same story.
I don't object to changing them, since we don't seem to be actively
adopting any new upstream versions; but again I can't get too excited.

> - psql_assert(!*text);
> + Assert(*text != '\0');

I think you got that one backwards.

> #include "c.h"

> +#ifdef USE_ASSERT_CHECKING
> +#include <assert.h>
> +#define Assert(p) assert(p)
> +#else
> +#define Assert(p)
> +#endif

Perhaps a comment would be in order here? Specifically something
about providing Assert() so that it can be used in both backend
and frontend code?

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2012-12-14 20:56:10 Re: Use of systable_beginscan_ordered in event trigger patch
Previous Message Dimitri Fontaine 2012-12-14 20:46:19 Re: Use of systable_beginscan_ordered in event trigger patch