From: Tom Lane <tgl@sss.pgh.pa.us>
To: pgsql-hackers@lists.postgresql.org
cc: =?koi8-r?B?9MHSwdPP1yDnxc/Sx8nKIPfJ1MHM2MXXyd4=?= <Tarasov-G@gaz-is.ru>
Subject: Re: compiling PL/pgSQL plugin with C++
In-reply-to: <51937.1559231664@sss.pgh.pa.us>
References: <b517ec3918d645eb950505eac8dd434e@gaz-is.ru>
 <51937.1559231664@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Thu, 30 May 2019 11:54:24 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <74480.1559252788.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Thu, 30 May 2019 17:46:28 -0400
Message-ID: <74481.1559252788@sss.pgh.pa.us>
Precedence: bulk

I wrote:
> I propose that we change src/tools/pginclude/cpluspluscheck so that
> it searches basically everywhere:
 =

> -for f in `find src/include src/interfaces/libpq/libpq-fe.h src/interfac=
es/libpq/libpq-events.h -name '*.h' -print | \
> +for f in `find src contrib -name '*.h' -print | \

After further experimentation with that, it seems like we'll have
to continue to exclude src/bin/pg_dump/*.h from the C++ check.
pg_dump uses "public" and "namespace" as field names in various
structs, both of which are C++ keywords.  Changing these names
would be quite invasive, and at least in the short run I see no
payoff for doing so.

ecpg/preproc/type.h is also using "new" as a field name, but it
looks like there are few enough references that renaming that
field isn't unreasonable.

There are various other minor issues, but they generally look
fixable with little consequence.

			regards, tom lane