PHP 5.2.6 pdo_pgsql is buggy with BLOB INSERT/UPDATE

Long story short, PHP 5.2.6 pdo_pgsql is buggy with BLOB INSERT/UPDATE. Both NULL and empty string are saved as NULL when pass into PostgreSQL, and so programming logic may break. It is now fixed in latest PHP CVS, both 5.2.x and 5.3.x. All packages newer than snapshot php5.2-200810130030.tar.gz. is safe from this issue. Please refer to PHP bug report for more information. As Drupal 7.x is now revamped with DBTNG and using PDO as the only default support database driver, this is a critical issue for its PostgreSQL support status. Patch is submitted and pending for review. Please refer to Drupal bug report for more information.

How to check if my PHP is safe from this bug?

You can follow the bug reproduction guideline and its latest version of code snippet. Check your result and see if all logical comparison of original data and fetched value are return as TRUE.

What can I do with this bug?

If you are a Drupal 7.x core developer which focusing on PostgreSQL support status, please download PHP snapshot newer than php5.2-200810130030.tar.gz manually, and give a hand for the commit of related Drupal bug report. If you need some help for the manual PHP installation, please refer to my HOWTO for more information. If you are normal Drupal user which will use PostgreSQL in coming future, please be patient and wait for the release of PHP 5.2.7 (it is now 5.2.7RC2). You may also keep your eyes on the update status of the Drupal bug report, and help the promote of using PHP 5.2.7 as minimal support version for Drupal 7.x public release.

HKDUG: 1st pre-meeting with coffee break

After a week from the successful Drupal section in BarCamp Hong Kong 2008, today we have our 1st pre-meeting for the startup of Hong Kong Drupal User Group (HKDUG), together with friends who are interested in using Drupal, and also plan for the detail of our coming off-line gathering on Sept. 25th. It is a nice gathering, especially with coffee break :D Today is a public holiday in Hong Kong, after the Mid_autumn Festival. This 5 members off-line gathering is hosted in Pacific Coffee of Festival Walk at Kowloon Tong. The target of today is very simple: we are going to host a another gathering on Sept. 25th, so just sit down and brainstorming the presentation schedule with coffee; on the other hand, think about if we are going to startup HKDUG with the support of our own portal page (e.g. http://drupal.org.hk/), discuss and handle those legal restriction based on Hong Kong Government.

Review from BarCamp Hong Kong 2008

I have a good day in BarCamp Hong Kong 2008: meet a lot of new friends (Drupal or not), join the section of "The Hong Kong Startup Association" and "Open Source + Microsoft" (it is a good talk show, even I don't really love M$ so much...), prepare a section for Drupal about "Drupal Theme Development", and also join the "Startup Lightning Talks" with topic of "eLearning in Hong Kong". I can only say that: it is great as I can join this event :D

Wirtting query in reserved word safe: any possible solution?

Reserved word conflict is an always pain for multiple DB backend supported system: Drupal also face this for many years (e.g. http://drupal.org/node/371, since June 30, 2002). This is the most complicated bottleneck for daily maintenance and introduce any new DB backend to Drupal: whenever existing DB vendor change their standard, we need to follow it; whenever a new DB backend introduce, another set of reserved words are coming in, too. There is many possible solution, e.g. prevent use of ANY reserved words based on requirement of ALL supported database engines (as like as Moodle's implementation); BTW, as this solution will left issue as ALWAYS OPEN, I am not going to discuss within this review. Another possibility is the use of escape characters, e.g. `` for MySQL, "" for PostgreSQL/Oracle/DB2 and [] for MSSQL. This approach is widely used for many successful projects, e.g. phpmyadmin, phppgadmin, Oracle/DB2/MSSQL EM. The primary consideration is: How to implement this syntax for Drupal, which is simple and elegant for both end user and DB abstraction designer? For sure that we will need some update for existing Drupal queries syntax, where the ultimate goal is query will finally present as following example before process by PHP database connection (e.g. SELECT batch FROM {batch} WHERE bid = :bid AND token = :token from line 15 of includes/batch.inc, CVS HEAD, rewrite with TNG DB standard). In case of MySQL, after translation it should looks like: SELECT `batch` FROM `batch` WHERE `bid` = :bid AND `token` = :token I will discuss different syntax change approach, based on: a) user experience, b) similar to ANSI coding style, c) backward compatibility, d) backend complexity, e) overall performance and f) workload for syntax conversion. A simple marking will be given for each item (e.g. good/functioning: 2; fine/not bad: 1; poor/not functioning: 0) so we can have some simple idea between different proposals. Here is a quick rundown of my review:

Forward a message but still leave a copy on the server?

I am using Debian etch for production, plus Exim4 with per user ~/Maildir support. Since I hope to forward each user message to their own public email for backup, Procmail FAQ give me a useful example. First of all, check if your Exim4 have ~/.procmailrc supported, which usually already there. Find the follow code snippet from /etc/exim4/exim4.conf.template: ##################################################### ### router/700_exim4-config_procmail

A new day, a new life, a next generation

Yesterday is my last working day for HKU CITE. After 3 annual holidays, I will in a new position on Monday. It is a secondary school and I will work as an IT Officer. Most duty and position are similar as now, but coming with better location, job title, working hour and also salary.

PostgreSQL 8.3 on Debian sid mini-HOWTO

This mini-HOWTO will guide you though the installation of PostgreSQL 8.3 on Debian sid. After install initial packages, you will need to create and configure both user account and database, which Debian installation script will not do for you.
Before start I will assume you have a complete installed and functional Debian sid box on hand. If you have no idea about this, please refer to my other article for more details.
This document is a refine and trim down version of my legacy artical which target for Debian etch. Most procedure are shared so you may also able to apply them in case of Debian etch.

Prevent '*Zone.Identifier*' files generate by WinXP SP3 and Samba3

My Samba is working fine before but some days ago, it keep on generating some '*Zone.Identifier*' files, e.g. DskPerf.zip:Zone.Identifier:$DATA, when copy file from WinXP SP3 to Samba. I can't delete them from both Windows and Linux, and I don't even understand why it come out suddently... Finally, openSUSE forum give me a workable solution (http://forums.opensuse.org/network-internet/387779-samba-file-transfer-creates-zone-identifier-files.html). Just add the following line to smb.conf: vfs objects = streams_xattr

Drupal 6.x + PDO_OCI: finally work together

After put down my multiple database backend research for Drupal among past 4 months, now finally get Drupal 6.x and PDO_OCI working together... It is all about my incorrect pdo_oci driver implementation... The progress is now available in here.

What is the bottleneck?

Pages

Subscribe to Edison Wong RSS