> Hi, > > I found this in the TODO list: > > Add API for 64-bit large object access > > If this is a still valid TODO item and nobody is working on this, I > would like to work in this.
Here are the list of functions think we need to change. 1) Frontend lo_* libpq functions(fe-lobj.c) lo_initialize() need to get backend 64-bit large object handling function's oid, namely lo_lseek64, lo_tell64, lo_truncate64, loread64, lowrite64(explained later). If they are not available, use older 32-bit backend functions. BTW, currently lo_initialize() throws an error if one of oids are not avilable. I doubt we do the same way for 64-bit functions since this will make 9.3 libpq unable to access large objects stored in pre-9.2 PostgreSQL servers. 2) Bakend lo_* functions (be-fsstubs.c) Add lo_lseek64, lo_tell64, lo_truncate64, loread64 and lowrite64 so that they can handle 64-bit seek position and data lenghth. 3) Backend inv_api.c functions 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. Comments, suggestions? -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers