Same problem with the latest snapshot.
I've setup pdo_odbc and I get the exact same symptoms, can select char and int fields, but not text or blob. The error that comes up in err_log is different though:
FATAL: emalloc(): Unable to allocate -2147483648 bytes
2147483648 is the maximum size of a text field. The most characters in any of the tuples in the test table is about 30.

With snapshot 200507112030 using the ifx_ functions it comes back with:
[Tue Jul 12 09:34:05 2005] [notice] child pid 2175 exit signal Segmentation fault (11)
[Tue Jul 12 09:34:06 2005] [notice] child pid 2176 exit signal Segmentation fault (11)
I'm having some difficulties with PDO now, it comes back with : "Failed to connect:could not find driver". This is probably just a misconfiguration problem on my end that I haven't managed to track down yet.
Note: When I tryed the latest snapshot I just did a "make install" over the top of the old one.

Sounds like you're missing an extension=pdo_odbc.so line from your php.ini.
Installing over the top of an existing install is usually ok, provided that you made a fresh, clean build for the new install.

Rightio, it was user error. I did an strace and I had php.ini in the wrong place, I've corrected it. Previously I configured the extensions dir as a configure option and compiled my own pdo.so and pdo_odbc.so so it worked ok.
"php -m" shows up PDO and pdo_sqlite. I thought PDO was going to be included with PHP and therefore would be in the latest snapshot or do you want me to get it from pear?

I've added an arbitrary limit of 64k per text column for now, so that PHP doesn't kill your apache instance off (it was trying to allocate 2GB + 1 bytes per text column).
It is likely that PDO_ODBC will now truncate any text columns that are longer than 64k; I'm working on a better long term fix.
The very next snapshot should give you a more decent experience until then.

This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Current CVS (and thus the next snapshot) now handle arbitrary length columns; enjoy!

That crash looks like the informix libraries are trying to call a NULL callback handler.
There's no way I can debug this without being able to sit down at the machine with my hands on gdb; Can I get a non-privileged account on that machine, so that I can build a CLI php and test it?

I've poked around, and this really looks like either a unixODBC or informix bug (perhaps both).
It's quite possible that PDO is doing something that unixODBC or informix doesn't like, but the problem is that unixODBC is trying to call a function that is set to NULL.
(gdb) info linkmap
00000000
00000000 /lib/libcrypt.so.1
00000000 /usr/lib/libz.so.1
00000000 /lib/libresolv.so.2
00000000 /lib/tls/libm.so.6
00000000 /lib/libnsl.so.1
00a40000 /usr/local/lib/libodbc.so.1
00000000 /lib/libdl.so.2
00000000 /lib/tls/libpthread.so.0
00000000 /lib/tls/libc.so.6
00000000 /lib/ld-linux.so.2
005e1000 /usr/lib/gconv/ISO8859-1.so
001f7000 /opt/informix/lib/cli/iclis09b.so
007d5000 /opt/informix/lib/esql/libifgls.so
00d89000 /opt/informix/lib/esql/libifglx.so
0039e000 /lib/libnss_files.so.2
00198000 /opt/informix/lib/esql/igo4a304.so
0098d000 /usr/local/lib/libodbccr.so.1
(gdb) where
#0 0x00000000 in ?? ()
fault here, calling a NULL function.
#1 0x00990ef2 in CLGetData (statement_handle=0x8faec48, column_number=2, target_type=1,
target_value=0x8fb383c, buffer_length=256, strlen_or_ind=0x8fb36c4) at SQLGetData.c:336
this address is in libodbccr.so.1, part of unix odbc
#2 0x00a58f0c in SQLGetData (statement_handle=0x8fae670, column_number=2, target_type=1,
target_value=0x8fb383c, buffer_length=256, strlen_or_ind=0x8fb36c4) at SQLGetData.c:412
this address is in libodbccr.so.1, part of unix odbc
#3 0x080abd8a in odbc_stmt_get_col (stmt=0x8fb7f94, colno=1, ptr=0xbfe6083c, len=0xbfe60838,
caller_frees=0xbfe60834) at /home/wez/php5-200509161630/ext/pdo_odbc/odbc_stmt.c:434
this address is in the pdo odbc driver.
What I suspect is the problem is that either informix doesn't set a flag to tell unixodbc about the functions it supports, or that unixodbc doesn't respect a flag that it should.
Ultimately, unixODBC should catch that NULL and report an error properly.
I don't think I can do anything while this crash problem exists, and I think you should file a bug report with the unix ODBC guys so that we can figure out what is going wrong, and then we can figure out how to make things work for you.
I'm happy to co-operate with them in tracking this down.

[2005-09-24 01:00 UTC] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".