Horton

Re: Inconsistencies around defining FRONTEND

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@anarazel.de>, 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-23T22:58:50Z
Lists: pgsql-hackers 
On Tue, Aug 23, 2022 at 5:56 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > Actually, I think we could fix these pretty easily too. See attached.
>
> Hmm, do these headers still pass headerscheck/cpluspluscheck?

I didn't check before sending the patch, but now I ran it locally, and
I did get failures from both, but they all seem to be unrelated.
Mainly, it's sad that I don't have Python.h, but I didn't configure
with python, so whatever.

> I might quibble a bit with the exact placement of the #ifndef FRONTEND
> tests, but overall this looks pretty plausible.

Yep, that's arguable. In particular, should the redo functions also be
protected by #ifdef FRONTEND?

I'd be more than thrilled if you wanted to adjust this to taste and
apply it, barring objections from others of course.

-- 
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