Jeremy Drake <[EMAIL PROTECTED]> 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. 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. 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. 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