Skip site navigation (1) Skip section navigation (2)

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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Re: [PATCH 1/5] Centralize Assert* macros into c.h so its common between backend/frontend
Date: 2013-01-08 20:55:24
Message-ID: 28190.1357678524@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Alvaro Herrera <alvherre(at)2ndquadrant(dot)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


In response to

Responses

pgsql-hackers by date

Next:From: Tomas VondraDate: 2013-01-08 20:56:41
Subject: Re: PATCH: optimized DROP of multiple tables within a transaction
Previous:From: Heikki LinnakangasDate: 2013-01-08 20:47:43
Subject: Re: [PATCH 2/5] Make relpathbackend return a statically result instead of palloc()'ing it

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group