This has been saved for the 8.2 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---------------------------------------------------------------------------
Tom Lane wrote:
> 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
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
