Received: from sss.pgh.pa.us (sss.pgh.pa.us [209.114.132.154]) by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id f190Asx48946; Thu, 8 Feb 2001 19:10:55 -0500 (EST) (envelope-from tgl@sss.pgh.pa.us) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.11.1/8.11.1) with ESMTP id f190Ao914791; Thu, 8 Feb 2001 19:10:50 -0500 (EST) To: Peter Eisentraut cc: pgsql-hackers@postgreSQL.org, pgsql-interfaces@postgreSQL.org Subject: Re: Plan for straightening out the include-file mess In-reply-to: References: Comments: In-reply-to Peter Eisentraut message dated "Fri, 09 Feb 2001 01:08:53 +0100" Date: Thu, 08 Feb 2001 19:10:50 -0500 Message-ID: <14788.981677450@sss.pgh.pa.us> From: Tom Lane X-Archive-Number: 200102/303 X-Sequence-Number: 4434 Peter Eisentraut 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