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
