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

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

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH 1/5] Centralize Assert* macros into c.h so its common between backend/frontend
Date: 2013-01-08 19:31:29
Message-ID: 20130108193129.GB8311@awork2.anarazel.de (view raw or flat)
Thread:
Lists: pgsql-hackers
On 2013-01-08 14:25:06 -0500, Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> > From: Andres Freund <andres(at)anarazel(dot)de>
> > c.h already had parts of the assert support (StaticAssert*) and its the shared
> > file between postgres.h and postgres_fe.h. This makes it easier to build
> > frontend programs which have to do the hack.
>
> This patch seems unnecessary given that we already put a version of Assert()
> into postgres_fe.h.  I don't think that moving the two different
> definitions into an #if block in one file is an improvement.  If that
> were an improvement, we might as well move everything in both postgres.h
> and postgres_fe.h into c.h with a pile of #ifs.

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. It seems the most
consistent to move all of that into c.h, enough of the assertion stuff
is already there, I don't see an advantage of splitting it across 3
files as it currently is.

Greetings,

Andres Freund

--
 Andres Freund	                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2013-01-08 19:35:12
Subject: Re: [PATCH 1/5] Centralize Assert* macros into c.h so its common between backend/frontend
Previous:From: Tom LaneDate: 2013-01-08 19:28:14
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