Re: Plan for straightening out the include-file mess

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgreSQL(dot)org, pgsql-interfaces(at)postgreSQL(dot)org
Subject: Re: Plan for straightening out the include-file mess
Date: 2001-02-09 00:10:50
Message-ID: 14788.981677450@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-interfaces

Peter Eisentraut <peter_e(at)gmx(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Clift 2001-02-09 02:01:42 SPI_exec - Trying to access SPI_tuptable - error of 'dereferencing pointer to incomplete type'
Previous Message Peter Eisentraut 2001-02-09 00:08:53 Re: Plan for straightening out the include-file mess

Browse pgsql-interfaces by date

  From Date Subject
Next Message Hiroshi Inoue 2001-02-09 05:02:18 Re: 7.1 beta 3 Linux ODBC BEGIN Behaviour
Previous Message Peter Eisentraut 2001-02-09 00:08:53 Re: Plan for straightening out the include-file mess