Jeremy Drake <[EMAIL PROTECTED]> writes: > On Fri, 23 Sep 2005, Tom Lane wrote: >> postgresql-fe.h defines a ton of stuff that has no business being >> visible to libpq's client applications. It's designed to be used by >> our *own* client-side code (psql and the like), but we have not made >> any attempt to keep it from defining stuff that would likely break >> other peoples' code.
> So does this mean that there is a different, more advanced and more likely > to break random other code, client library where this call would fit > better? I've been thinking more about this and come to these conclusions: 1. libpq_fe.h definitely cannot include postgres_fe.h; in fact, it has no business even defining a type named "int64". That is way too likely to collide with symbols coming from elsewhere in a client compilation. I think what we need is to declare a type named "pg_int64" and use that in the externally visible declarations. The most reasonable place to put the typedef is postgres_ext.h. This will mean making configure generate postgres_ext.h from a template postgres_ext.h.in, but that's no big deal. 2. We need a strategy for what to do when configure doesn't find a working int64 type. My inclination is to just not export the functions in that case. So normally, postgres_ext.h would contain something like #define HAVE_PG_INT64 1 typedef long long int pg_int64; but neither of these would appear if configure couldn't find a working type. In libpq-fe.h, we'd have #ifdef HAVE_PG_INT64 extern pg_int64 lo_lseek64(PGconn *conn, int fd, pg_int64 offset, int whence); extern pg_int64 lo_tell64(PGconn *conn, int fd); #endif and similarly for all the code inside libpq. The reason this seems like a good idea is that client code could key off "#ifdef HAVE_PG_INT64" to detect whether the lo64 functions are available; which is useful even if you don't care about machines without int64, because you still need to think about machines with pre-8.2 PG installations. 3. This is still not 100% bulletproof, as it doesn't address situations like building PG with gcc and then trying to compile client apps with a vendor cc that doesn't understand "long long int". The compile would choke on the typedef even if you weren't trying to use large objects at all. I don't see any very nice way around that. It might be worth doing this in postgres_ext.h: #ifndef NO_PG_INT64 #define HAVE_PG_INT64 1 typedef long long int pg_int64; #endif which would at least provide an escape hatch for such situations: define NO_PG_INT64 before trying to build. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend