Hi: This is an excerpt from ext/pgsql/pgsql.c, in pg_lo_open:
--- if (strchr(mode_string, 'w') == mode_string) { pgsql_mode |= INV_WRITE; create = 1; if (strchr(mode_string, '+') == mode_string+1) { pgsql_mode |= INV_READ; } } pgsql_lofp = (pgLofp *) emalloc(sizeof(pgLofp)); if ((pgsql_lofd = lo_open(pgsql, oid, pgsql_mode)) == -1) { if (create) { if ((oid = lo_creat(pgsql, INV_READ|INV_WRITE)) == 0) { efree(pgsql_lofp); php_error_docref(NULL TSRMLS_CC, E_WARNING, "Unable to create PostgreSQL large object."); RETURN_FALSE; } else { if ((pgsql_lofd = lo_open(pgsql, oid, pgsql_mode)) == -1) { if (lo_unlink(pgsql, oid) == -1) { efree(pgsql_lofp); ... } ... registers resource and returns ... --- If I'm reading this correctly, it looks like a call to pg_lo_open (with an object identifier specified explicitly in $oid) can theoretically return a file handle pointing to a different, newly-created large object in the case that the initial open failed. If this is the case, it seems unintuitive and very cumbersome to handle from user-space. Can we change the 'if (create) {' branch to only be triggered when the oid was left unset (ensuring that the open() failure actually gets back to the caller)? Best Regards, - Dave [EMAIL PROTECTED] -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php