PEAR is archived and read-only

This mirror preserves historical PEAR package releases and metadata so existing references remain available.

Home » Database » DB » Bug #3115

condition failure in pgsql tableinfo() w/db_dataobject

Details

Submitted2005-01-05 19:34 UTC
Fromjacdx at jacobhanson dot com
AssignedD
StatusDuplicate
PackageDB
PHP Version5.0.3
OSxp pro
Roadmaps(Not assigned)

Comments

[2005-01-05 19:34 UTC] jacdx at jacobhanson dot com

Description:
------------
condition failure in pgsql tableinfo() w/db_dataobject

Using the latest win32 pgsql 8.0 installer (rc2), the latest
releases of db and db_dataobject (as of today).

I'm using db_dataobject's entity generator (this could be a bug in db_dataobject as well). When trying to generate entities, I get this error:

[db_error: message="DB Error: insufficient data supplied" code=-20 mode=callback callback=pearErrorHandler prefix="" info="SELECT c.relname as "Name" FROM pg_class c, pg_user u WHERE c.relowner = u.usesysid AND c.relkind = 'r' AND not exists (select 1 from pg_views where viewname = c.relname) AND c.relname !~ '^(pg_|sql_)' UNION SELECT c.relname as "Name" FROM pg_class c WHERE c.relkind = 'r' AND not exists (select 1 from pg_views where viewname = c.relname) AND not exists (select 1 from pg_user where usesysid = c.relowner) AND c.relname !~ '^pg_'"]

The query in error actually works fine. I traced the problem down to a call on line 187 of DB_Dataobject's Generator.php,
which is made to DB->tableInfo. Even though Generator is only passing in a table name string argument, the Pgsql driver on line 723, fails to identify the argument correctly, misinterpreting it as a valid result in that conditional block, then raising an error afterwards after it actually checks whether the result is valid or not.

Changing line 723 of the pgsql driver from:
if (isset($result->result)) {

to:
if (isset($result->result) && $result->result != null) {

fixes this problem. As far as I can tell, $result->result isn't set, so isset($result->result) should fail, but it isn't. This may be DB_DataObject's fault, but adding the extra condition in DB's pgsql driver will make it more robust.