Re: 64-bit API for large objects - Mailing list pgsql-hackers

Jeremy Drake <pgsql@jdrake.com> 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 1typedef 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_INT64extern 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 1typedef 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