> > 3) Backend inv_api.c functions(Nozomi Anzai) > > > > No need to add new functions. Just extend them to handle 64-bit data. > > > > BTW , what will happen if older 32-bit libpq accesses large objects > > over 2GB? > > > > lo_read and lo_write: they can read or write lobjs using 32-bit API as > > long as requested read/write data length is smaller than 2GB. So I > > think we can safely allow them to access over 2GB lobjs. > > > > lo_lseek: again as long as requested offset is smaller than 2GB, there > > would be no problem. > > > > lo_tell:if current seek position is beyond 2GB, returns an error. > > > Even though iteration of lo_lseek() may move the offset to 4TB, it also > makes unavailable to use lo_tell() to obtain the current offset, so I think > it is reasonable behavior. > > However, error code is not an appropriate one. > > + if (INT_MAX < offset) > + { > + ereport(ERROR, > + (errcode(ERRCODE_UNDEFINED_OBJECT), > + errmsg("invalid large-object > descriptor: %d", fd))); > + PG_RETURN_INT32(-1); > + } > > According to the manpage of lseek(2) > EOVERFLOW > The resulting file offset cannot be represented in an off_t. > > Please add a new error code such as ERRCODE_BLOB_OFFSET_OVERFLOW.
Agreed. -- Nozomi Anzai SRA OSS, Inc. Japan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers