Thanks for this explanation.
My migration somehow slipped this change (the table 'turba_objects' 
existed already in the horde-3-myslq-DB with 'object_members' of type 
'blob').
I will now check all DB-fields for correct type.

This is the problem. It's not supposed to be bytea, if created through 
Horde's migration scripts, this field is of type "text.

The problem seems to be located in turba/lib/Driver/Sql.php, the 
search-function there does not recognize the '__members'-value 
returned from postgresql as blob and therefore does not use 
'binaryToString()' on it.

I found a workaround by setting the turba-attribute 'type' => 'image' 
for '__members' in turba/attributes.local.php, this forces the use of 
'binaryToString' on the '__members'-value, which is then recognized 
and used correctly. This solution works for my setup with postgresql 
as only source of contact-lists, but will not work if contact lists 
come from other sources too, e.g. LDAP.

I assume, the correct solution has to be somewhere in the 
postgresql-driver when handling bytea-values, but I do not know enough 
of php for finding it.

Andreas

Cannot reproduce. Can you provide a backtrace?

I get the following error message in the system log if the field 
'object_member'  in table 'turba_objects' is not NULL

HORDE [turba] PHP ERROR: strlen() expects parameter 1 to be string, 
resource given [pid 10010 on line 470 of 
"/var/www/horde/turba/lib/Driver.php"]

The corresponding setting in turba/config/backends.local.php is the default:
  $cfgSources['localsql'] = array(
    'map' => array(
         '__members' => 'object_members',
))

If I comment out this setting, the error message disappears.

I am using postgresql as db-backend, the type of 'object_member' is 'bytea'.

Thanks for any help on this.

Andreas