From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: Nazir Bilal Yavuz <byavuz81@gmail.com>,
        Peter Eisentraut <peter@eisentraut.org>,
        Bertrand Drouvot <bertranddrouvot.pg@gmail.com>,
        pgsql-hackers@lists.postgresql.org
Subject: Re: Enable -Wstrict-prototypes and -Wold-style-definition by default
In-reply-to: <pvwv3lp7te6nxbmb2mr6oiyxcwf5fq4vjbbtf5s2yu6bpyqn6z@k3gc2bjmlcbu>
References: <aa73q1aT0A3/vke/@ip-10-97-1-34.eu-west-3.compute.internal>
 <44885d54-0376-46b3-b574-59e0e3098580@eisentraut.org>
 <dfb1373e-258f-42b7-ac76-0f5858936dfa@eisentraut.org>
 <CAN55FZ1VDwJ-ZD092ChYf++huP+-S3Cg45tJ8jNH5wx2c4BHAg@mail.gmail.com>
 <784253.1773853383@sss.pgh.pa.us>
 <pvwv3lp7te6nxbmb2mr6oiyxcwf5fq4vjbbtf5s2yu6bpyqn6z@k3gc2bjmlcbu>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Wed, 18 Mar 2026 13:26:26 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <803739.1773855226.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Wed, 18 Mar 2026 13:33:46 -0400
Message-ID: <803740.1773855226@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/803740.1773855226%40sss.pgh.pa.us>
Precedence: bulk

Andres Freund <andres@anarazel.de> writes:
> On 2026-03-18 13:03:03 -0400, Tom Lane wrote:
>> Yeah, I see that too.  I believe the problem is that headerscheck
>> doesn't cause POSTGRES_ECPG_INTERNAL to become defined, so that
>> what the compiler is seeing is (from sqlca.h):
>> =

>> #ifndef POSTGRES_ECPG_INTERNAL
>> #define sqlca (*ECPGget_sqlca())
>> #endif

> I don't even really understand what that POSTGRES_ECPG_INTERNAL business=
 is
> about. Is that really just so we can use a local "sqlca" variable in som=
e of
> our own ecpglib code while code using ecpg can't do that?  Please tell m=
e it
> ain't so.

Looks like it's so --- AFAICS, POSTGRES_ECPG_INTERNAL isn't tested
anywhere except in this fragment in sqlca.h.

>> We could plausibly fix this either by
>> =

>> (1) renaming ecpg_init_sqlca's parameter to something else;
>> =

>> (2) ensuring that POSTGRES_ECPG_INTERNAL is defined.  I'd be inclined
>> to make ecpglib_extern.h do that rather than expecting headerscheck
>> to know about it.

>> Neither of these options are beautiful, but perhaps #1 is slightly
>> less ugly.  Any preferences?

> 1) seems to be the preferrable approach. It's what code using ecpg alrea=
dy has
> to do, right?

I think that from the point of view of ecpg client applications,
"sqlca" is supposed to be a library-defined global variable
(and this macro is about making it thread-local).
They'd not really have use for local variables named that.

			regards, tom lane