Re: 64-bit API for large objects

On Fri, 23 Sep 2005, Tom Lane wrote:

> Jeremy Drake <pgsql(at)jdrake(dot)com> writes:
> > 2) The lo_*64, in order to be convenient from the client end, have
> > functions added to libpq as the existing lo_* functions. The client side
> > of libpq did not previously know anything about int64 or how to
> > send/receive them. I added an include of postgres-fe.h (which according
> > to the comment in that file looks like it should go there) so int64 would
> > be defined,
>
> Unfortunately that's completely unacceptable from a namespace-pollution
> point of view.

I don't quite understand. Allow me to cite the source, so we both are
referring to the same thing here...

jeremyd(at)pluto postgresql-8.0.3 $ head -n17 src/include/postgres_fe.h
/*-------------------------------------------------------------------------
*
* postgres_fe.h
* Primary include file for PostgreSQL client-side .c files
*
* This should be the first file included by PostgreSQL client libraries and
* application programs --- but not by backend modules, which should include
* postgres.h.
*
*
* Portions Copyright (c) 1996-2005, PostgreSQL Global Development Group
* Portions Copyright (c) 1995, Regents of the University of California
*
* $PostgreSQL: pgsql/src/include/postgres_fe.h,v 1.10 2004/12/31 22:03:19 pgsql Exp $
*
*-------------------------------------------------------------------------
*/

Now I may not completely understand the term "client", but I think libpq
is a "client library" and anything which may use it would be an
"application program". So it seems it was an oversight on the part of
libpq to not include it. Does the term "client" not mean what I thought
it did (anything which connects to a postgresql server)?

>
> The real problem here is that int64 isn't a well-defined portable
> datatype, and so it's going to be very hard to export these functions in
> a way that won't break on different platforms, applications compiled
> with a different compiler than libpq was, etc.

Umm, what wouldn't break if you switched compilers in a way that redefined
sizeof(things)? I happen to know, even using the same compiler but just
changing a compile flag (-m64) which changes sizes of integral types
(sizeof(long) from 32 to 64 bits) will make such actions stop working on
one of my tested platform. It sucks, I happen to not be fond of this
because I tend not to have every library which is on my box built for
both, but it is the way life is. I do not know of a platform where the
size of an integral type can change and still be able to link against
libraries and things. And if the size of some type is not changing, then
things should already be correctly set for the platform. But I admit I
have not met every platform in existance. Do you happen to be able to
cite a platform where this is the case?

>
> For that matter, we can't even guarantee that they work at all: not all
> platforms even *have* int64 types. We have so far avoided putting any
> fundamental dependencies on int64 arithmetic into the system, and I'm a
> bit worried that this patch will break LO support entirely on platforms
> that don't have working int64 arithmetic.

They should in fact break gracefully on such platforms, or at least as
gracefully as any other int64-using code might. I did check a couple
places for #ifdef INT64_BROKEN (or whatever it was called) to make sure
that on those platforms something at least somewhat sane would happen.
(they use 32 bits instead). Also, on those platforms, you could always
use the non-64 versions if you were concerned about that. The patches
would allow seeking past the old limit using the 32 function in stages
(seek 2G, seek 2G, seek 2G would put you at 6G) if you do not mind wierd
return values and tell not working. And if you use a platform which
does not support 64bit integral types, then you cannot reasonably expect
those functions to work correctly anyway. But they should compile at
least.

>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
>

--
I don't wanna argue, and I don't wanna fight,
But there will definitely be a party tonight...