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: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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:36:19
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Andres Freund wrote:
> On 2013-01-08 14:35:12 -0500, Tom Lane wrote:
> > Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> > > On 2013-01-08 14:25:06 -0500, Tom Lane wrote:
> > >> This patch seems unnecessary given that we already put a version of Assert()
> > >> into postgres_fe.h.
> > 
> > > The problem is that some (including existing) pieces of code need to
> > > include postgres.h itself, those can't easily include postgres_fe.h as
> > > well without getting into problems with redefinitions.
> > 
> > There is no place, anywhere, that should be including both.  So I don't
> > see the problem.
> 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.

Álvaro Herrera      
PostgreSQL Development, 24x7 Support, Training & Services

In response to


pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2013-01-08 20:38:20
Subject: Re: [PATCH 2/5] Make relpathbackend return a statically result instead of palloc()'ing it
Previous:From: Simon RiggsDate: 2013-01-08 20:30:49
Subject: Re: Cascading replication: should we detect/prevent cycles?

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