Re: 64-bit API for large objects

Jeremy Drake <pgsql(at)jdrake(dot)com> writes:
> In any case, are there any comments on the changes below libpq (the
> functions visible to queries on down)?

Within the backend, I don't see the point in maintaining a distinction
between 32- and 64-bit APIs for inv_api.c: you should just switch 'em
to use int64. You did it that way for inv_getsize but then proceeded
to add separate inv_seek64/tell64 functions, which is inconsistent.
The submitted version of lo_tell64 isn't even calling the right one :-(

The 32-bit version of lo_tell will need to check and error out if the
value it'd need to return doesn't fit in int32. (Come to think of it,
so should the 32-bit version of lo_lseek.)

All of the LO code needs to be eyeballed to make sure it still behaves
sanely if "int64" is really only 32 bits.

It would probably be a good idea also to introduce some overflow checks
to detect cases where the current LO offset would overflow int64 after a
read, write, or seek. This is missing from the existing code :-(
It is possible to code overflow checks that work regardless of the size
of "int64"; see int8.c for some inspiration. I'd suggest also that the
offset be defined as signed not unsigned (int64 not uint64) as this will
simplify the overflow checks and eliminate the prospect of scenarios
where lo_tell64 cannot return a correct value.

regards, tom lane