Horton

Re: Inconsistencies around defining FRONTEND

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter.eisentraut@enterprisedb.com>, Noah Misch <noah@leadboat.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, samay sharma <smilingsamay@gmail.com>, Nazir Bilal Yavuz <byavuz81@gmail.com>
Date: 2022-08-24T14:40:01Z
Lists: pgsql-hackers 
On Tue, Aug 23, 2022 at 9:55 PM Andres Freund <andres@anarazel.de> wrote:
> We could, if we make xlogreader.c and the rmgrdesc routines built as part of
> src/common. I don't really see how otherwise.

After a little bit of study, I agree.

It looks to me like -DFRONTEND can be removed from
src/fe_utils/Makefile and probably also src/common/unicode/Makefile
without changing anything else, because the C files in those
directories seem to be frontend-only and they already include
"postgres_fe.h". I think we should go ahead and do that, and also
apply the patch I posted yesterday with whatever bikeshedding seems
appropriate.

It doesn't really seem like we have a plausible alternative to the
current system for src/common or src/port.

pg_rewind and pg_waldump seem to need the xlogreader code moved to
src/common, as Andres proposes. I'm not volunteering to tackle that
right now but I think it might be a good thing to do sometime.

--
Robert Haas
EDB: http://www.enterprisedb.com

Commits

  1. Don't define FRONTEND for ecpg libraries

  2. Don't define FRONTEND for initdb

  3. Don't define FRONTEND for libpq