This thread:
http://archives.postgresql.org/pgsql-ports/2006-06/msg00005.php
points up that if a client program would like to refer to datatype
OIDs by means of the pg_type.h macros (ie, write "INT4OID" and not
"23"), it's currently forced to include postgres.h, which is not
a good idea for a number of reasons. We intend postgres.h for use
by backend-side code; frontend code ought to use postgres_fe.h, and
indeed a plain libpq client shouldn't be including either. There's
way too much pollution of the client namespace from either file.
I ran into this same problem last week when I wanted to clean up
some hard-coded OIDs in psql's print.c. I did the same thing the
Qt people did, ie, #include postgres.h, but it's a really ugly hack.
I think it'd be a good idea to fix things so that the type OID macros
are available to frontend code without having to break any rules about
what to include. I looked at whether we could sanitize
catalog/pg_type.h so it could be used in a frontend environment, but
there are a couple obstacles there:
* We'd have to move the extern declarations for catalog/pg_type.c
somewhere else, and there's not an obvious candidate.
* There are still the BKI macros (CATALOG, DATA, etc) which really
should not be exported to client code ... DATA in particular seems like
a pretty obtrusive choice of macro name.
The alternative I'm currently thinking about is to build and install an
auto-generated file comparable to fmgroids.h, containing *only* the type
OID macro #defines extracted from pg_type.h. This would require just a
trivial amount of sed hacking.
I'm not entirely clear where to install such a thing though. The
fmgroids.h precedent suggests server/utils/fmgroids.h, but if this is
intended for client-side use it shouldn't go under /server. I'm
tempted to install it as "pgtypeoids.h" at the top level of the
installation include directory ... but then I'm not clear which source
directory ought to generate it.
Thoughts, objections, better ideas?
regards, tom lane
