On 2013-01-18 10:33:16 -0500, Tom Lane wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> > Here's a different idea: move all the Assert() and StaticAssert() etc
> > definitions from c.h and postgres.h into a new header, say pgassert.h.
> > That header is included directly by postgres.h (just like palloc.h and
> > elog.h already are) so we don't have to touch the backend code at all.
> > Frontend programs that want that functionality can just #include
> > "pgassert.h" by themselves. The definitions are (obviously) protected
> > by #ifdef FRONTEND so that it all works in both environments cleanly.
>
> That might work. Files using c.h would have to include this too, but
> as described it should work in either environment for them. The other
> corner case is pg_controldata.c and other frontend programs that include
> postgres.h --- but it looks like they #define FRONTEND first, so they'd
> get the correct set of Assert definitions.
>
> Whether it's really any better than just sticking them in c.h isn't
> clear.
I don't really see an advantage. To me providing sensible asserts sounds
like a good fit for c.h... And we already have StaticAssert*,
AssertVariableIsOfType* in c.h...
> Really I'd prefer not to move the backend definitions out of postgres.h
> at all, just because doing so will lose fifteen years of git history
> about those particular lines (or at least make it a lot harder to
> locate with git blame).
I can imagine some ugly macro solutions to that problem (pgassert.h
includes postgres.h with special defines), but that doesn't seem to be
warranted to me.
The alternative seems to be sprinkling a few more #ifdef FRONTEND's in
postgres.h, if thats preferred I can prepare a patch for that although I
prefer my proposal.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
