PostgreSQL lo_lseek64()/etc support.

From: Date: Mon, 13 Jan 2014 09:48:43 +0000
Subject: PostgreSQL lo_lseek64()/etc support.
Groups: php.internals 
Request: Send a blank email to internals+get-71108@lists.php.net to get a copy of this message
Hi all,

PostgreSQL 9.3 has support for 2GB+ large object support via
new APIs. e.g. lo_lseek64(), lo_tell64()

I've made patch that supports new 64bit large object APIs.

https://gist.github.com/yohgaki/35b12a48ac6332633e60

It adds new functions pg_lo_seek64(), pg_lo_tell64, pg_lo_truncate64().
However, these new functions are not mandatory. It could be made to use
php.ini setting which specifies libpq API is used by
pg_lo_seek()/pg_lo_tell()/
pg_lo_truncate().

libpq's lo_lseek(), lo_tell() will be legacy and unused APIs in the long
run.
Therefore, it may be better to change API to be used according to php.ini
setting. e.g. When pgsql.server_version=9.3 (or greater), use lo_*64()
if it's available.

Pros.
 - No additional API exposed.
 - No legacy API in the future.
 - Old code can extend capability w/o code change.
 - No additional user code is required to detect and switch API.
 - No query is required to detect PostgreSQL server version when
   php.ini based switch is used.

Cons.
 - Additional php.ini that specifies server version.

Even though I've made patch that simply exposes new libpq APIs,
patch that has php.ini switch is better. IMO.

Any comments?
If there aren't any objections, I'll create and commit patch that uses
php.ini to change pg_lo_*() behavior.

Note about libpq's lo_*64() APIs:
These APIs returns -1(failure) always if server version is less than
PostgreSQL 9.3.

Note for 32bit platforms:
Since PHP int is 32bit int, 64bit support could be used but it's limited
by 32bit int.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net


Thread (2 messages)

« previous php.internals (#71108) next »