Peter Eisentraut <peter_e@gmx.net> writes:
> This is only part of a larger problem, namely that over time it gets more
> likely that some public header file will depend on config.h. For example,
> the libpq++ one's already do. The SSL support in libpq currently requires
> the user to define USE_SSL themselves. int8 support in ecpg also requires
> configuration information.
Yes, I had noticed that but didn't have a solution, so I was just
leaving the issue at status quo for now. As you say, pulling config.h
into client-visible headers is a big pollution of their namespace,
so we need to avoid it if possible.
As far as the Oid typedef goes, it'd be possible to have configure
generate postgres_ext.h from postgres_ext.h.in and insert the proper
typedef, so that there's no added namespace pollution there. This
answer does not scale real well, but it might be enough for Oid and
int8 support.
regards, tom lane