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 some of
> our own ecpglib code while code using ecpg can't do that? Please tell me 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 already 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
