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
