On 2013-01-18 10:33:16 -0500, Tom Lane wrote: > Alvaro Herrera <alvhe...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers