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 ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match