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

Thread added to TODO.  As far as I can see, this thread never produced
an patch that could be applied.

---------------------------------------------------------------------------

Tom Lane wrote:
> 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 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
> 

--  Bruce Momjian   http://candle.pha.pa.us EnterpriseDB    http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +