Re: 64-bit API for large objects

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? If so, I would be happy to change the patch to put it there. I
did not see it, but I did not look very hard.

If not, what is a client side programmer to do if they want to pass int64s
around? Every client app has to basically write their own htonll (or
whatever you want to call it) and perform their own detection of what type
is a 64bit int, and cache the oids for the fastcall interface themselves?
There seems to be a lot of overhead which libpq saves you from. Or the
client program could perform the detection of the type, and also detect a
function which would reasonably serve as an atoll on the platform, and
snprintf(buf, 1024, "SELECT lo_seek64(%d, %lld, %d)", fh, offset,
SEEK_SET); exec the buf, check to see if any tuples came back, if so (get
the first column of the first tuple, call atoll on that) else handle
error, and in either case free the result?

In any case, are there any comments on the changes below libpq (the
functions visible to queries on down)? I don't want to get hung up in the
client issues just to find out later that the server stuff was completely
insane anyway... The client library seems to me to be less important
anyway. If the server can support it, the client can always manage to do
it some how, and then once the client lib can support it, it should be
fairly transparent to swap that out later, so that code that worked around
could be updated without immediately breaking all other code working
around.

So that means that if I get good feedback on the server side code, I could
start having people code to it using one of the above workaround methods
listed, and then if we manage to come up with some way which would be more
"correct" (if that is the right word) than the libpq hack I did then they
could gradually switch over to that (or use sed -i).

--
All that glitters has a high refractive index.