Re: Re: [PATCH 1/5] Centralize Assert* macros into c.h so its common between backend/frontend - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Re: [PATCH 1/5] Centralize Assert* macros into c.h so its common between backend/frontend
Date
Msg-id 28190.1357678524@sss.pgh.pa.us
Whole thread Raw
In response to Re: Re: [PATCH 1/5] Centralize Assert* macros into c.h so its common between backend/frontend  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: Re: [PATCH 1/5] Centralize Assert* macros into c.h so its common between backend/frontend
List pgsql-hackers
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Andres Freund wrote:
>> Sorry, misremembered the problem somewhat. The problem is that code that
>> includes postgres.h atm ends up with ExceptionalCondition() et
>> al. declared even if FRONTEND is defined. So if anything uses an assert
>> you need to provide wrappers for those which seems nasty. If they are
>> provided centrally and check for FRONTEND that problem doesn't exist.

> I think the right fix here is to fix things so that postgres.h is not
> necessary.  How hard is that?  Maybe it just requires some more
> reshuffling of xlog headers.

That would definitely be the ideal fix.  In general, #include'ing
postgres.h into code that's not backend code opens all kinds of hazards
that are likely to bite us sooner or later; the incompatibility of the
Assert definitions is just the tip of that iceberg.  (In the past we've
had issues around <stdio.h> providing different definitions in the two
environments, for example.)

But having said that, I'm also now remembering that we have files in
src/port/ and probably elsewhere that try to work in both environments
by just #include'ing c.h directly (relying on the Makefile to supply
-DFRONTEND or not).  If we wanted to support Assert use in such files,
we would have to move at least the Assert() macro definitions into c.h
as Andres is proposing.  Now, I've always thought that #include'ing c.h
directly was kind of an ugly hack, but I don't have a better design than
that to offer ATM.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: [PATCH 2/5] Make relpathbackend return a statically result instead of palloc()'ing it
Next
From: Tomas Vondra
Date:
Subject: Re: PATCH: optimized DROP of multiple tables within a transaction