Portable interfaces ...

I wanted to know exactly which header files I can use portably.

For example, on my system (Gentoo Linux), libpq-fe.h and postgres_ext.h
are both installed in /usr/include - thus I'm assuming they (or at least
libpq-fe.h, which includes postgres_ext.h) can be assumed to be
available on all unix systems that have postgres installed with 'make
install'.

However, also on Gentoo, a '/usr/include/postgresql' directory is
created with 'informix', 'internal', 'pgsql' and 'server'
subdirectories. These subdirectories contain more headers, most of
which I'm assuming are for internal stuff.

I have need to use two files out of this postgresql directory.
Specifically:
server/catalog/pg_type.h to get the OID ID's for all the default types
(I'm not using it for 'special' types, just the standard ones, eg.
INT8OID, etc).
server/mb/pg_wchar.h for unicode translation support (I'm assuming if
I have a unicode field, that it will actually be represented in a query
as a multi-byte char array, which I can then use pg_mb2wchar to convert
into a wchar_t *).

My question is, what is the likelihood of these headers being on most
unix systems with postgres installed? What is the likelyhood of them
being under /usr[/local]/postgresql? What is the likelyhood that these
file names may change, or move? and what about windows systems?

Unfortunately, the standard API as provided by libpq-fe.h is not really
extensive enough to be able to write any kind of reasonably complex
application that wants to do things like support localization, or verify
the data type is what we expect (or, let the database tell it the data
type without having to store it or know it in advance).

Incidentally, I do note that pg_config --includedir-server ==
/usr/include/postgresql/server on my system, however I do NOT know if
pg_config is a standard script installed with make install (and thus if
I can rely on it to point to the server include directory - or, as
mentioned above, whether the relative paths listed above are guarenteed
to stay the same).

Any help appreciated - and if any PG devs are listening, is it possible
to get either the 'default' API expanded, or document what users of
libpq can reasonably expect to exist on any system with libpq (and
associated headers) can expect to be available? I'd prefer to use the
#define's and localization routines within postgres itself, since its
the only way to ensure complete compatibility and correctness ... but if
its non-portable, I'm going to have to use my own #define's and portable
calls, which increases the chances of incompatibility with postgres :(

A coder in need ...

--
PreZ
Founder
The Neuromancy Society
http://www.neuromancy.net