Re: Portable interfaces ... - Mailing list pgsql-interfaces

Preston A. Elder wrote:
> I wanted to know exactly which header files I can use portably.

You can use exactly the interfaces (headers and functions) described in 
the documentation.  No more, no less.

> 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'.

Building libpq programs is described here: 
http://www.postgresql.org/docs/7.4/static/libpq-build.html

Any installation that claims to be ready for libpq development should 
provide libpq-fe.h and dependent headers in a documented location.

> 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.

Just because a file exists doesn't mean you should concern yourself with 
how to use it.  The documentations of the interfaces describe what you 
need to use when, how, and for what.  In this case, theses files relate 
to ECPG and server-side functions.  The pgsql directory looks bogus.

> 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).

It might be preferrable to get the type names by selecting from the 
system catalog pg_type.

>   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 *).

You could do that, but the PostgreSQL routines you refer to are not 
intended for client programs.  You should look in your C library for 
this functionality.

> 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?

That's very difficult to tell.  My advice is to stick to the 
documentation, and if the steps described in the documentation don't 
work, complain to the sysadmin/distributor/installer/packager.

> 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).

libpq isn't supposed to be a very high-level API.  If you want to write 
in C, maybe you'll be happier with ODBC.

> 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).

Again, follow the documentation.  If the documentation says to use 
pg_config and pg_config does not exist, complain to your packager.  
However, if pg_config were actually missing, a lot of other packages 
would break, so it's quite safe.