Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:71108 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 63837 invoked from network); 13 Jan 2014 09:49:27 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 13 Jan 2014 09:49:27 -0000 Authentication-Results: pb1.pair.com smtp.mail=yohgaki@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=yohgaki@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.172 as permitted sender) X-PHP-List-Original-Sender: yohgaki@gmail.com X-Host-Fingerprint: 209.85.217.172 mail-lb0-f172.google.com Received: from [209.85.217.172] ([209.85.217.172:33757] helo=mail-lb0-f172.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id DA/52-44475-6A6B3D25 for ; Mon, 13 Jan 2014 04:49:26 -0500 Received: by mail-lb0-f172.google.com with SMTP id c11so911541lbj.31 for ; Mon, 13 Jan 2014 01:49:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=MKDmz4IIsIZNLuWfUVdPwJqbEt5m/eJjSUk+yE+U1Mw=; b=yzNzoEop04kVvRl4Xaqp+WyQ5MLTtZftMFM4GdeWLJWDp04kRe6rDWZzpXqYqBGz3R hLhN4gh/3OOT9pye0nuPqZ3V3MDqVk6GPLNVcCSoYX6KDNLCIMYoHGoZquDwlBQ9q9d9 joAx2pYenmqZCWPeDhMciwbjgpZU46K70BOnv7LfHcilE8FwIJsfvSDGEHfhxANSXZYr vAKpTgjjO+00iRBQgFlt1cLeSdqVGjkMMPzl4wbWuqnHJsBrWgFW4/RcRu66y+p4fE/q VXFTegU7jeAe75BApUCXy+hIlc0T6g6r6Rx2RMfDh/3yuS5VDouwxvSofpGt7xgN4YFS aLIg== X-Received: by 10.152.36.101 with SMTP id p5mr229527laj.67.1389606563357; Mon, 13 Jan 2014 01:49:23 -0800 (PST) MIME-Version: 1.0 Sender: yohgaki@gmail.com Received: by 10.112.6.68 with HTTP; Mon, 13 Jan 2014 01:48:43 -0800 (PST) Date: Mon, 13 Jan 2014 18:48:43 +0900 X-Google-Sender-Auth: WetL4bVPOjSt1EO_CsAk2NRerUk Message-ID: To: "internals@lists.php.net" Content-Type: multipart/alternative; boundary=089e0158b5bc96292c04efd6fdeb Subject: PostgreSQL lo_lseek64()/etc support. From: yohgaki@ohgaki.net (Yasuo Ohgaki) --089e0158b5bc96292c04efd6fdeb Content-Type: text/plain; charset=UTF-8 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 --089e0158b5bc96292c04efd6fdeb--