DB_DataObject with PgSQL: Schema in table name and no keys defined.

Recently I was having troubles using DB_Dataobject with PostgreSQL and wanted to share my findings. The generator was adding the schema name to the table names, so the classes were Schema_TableName and the tables in the generated .ini file were schema.tableName. Also no keys were being defined in the generated .ini file. This can be fixed by using generator_strip_schema in the DB_DataObject options. You can view http://pear.php.net/bugs/bug.php?id=4203 to see more. The bug is closed but the documentation does not properly reflect these changes. I added 'generator_strip_schema' => 1, to the options static property array... $do_options = &PEAR::getStaticProperty('DB_DataObject','options'); $do_options = array( 'database' => $strDSN, 'schema_location' => './../DataObjects', 'class_location' => './../DataObjects', 'require_prefix' => 'DataObjects/', 'class_prefix' => 'DataObjects_', 'generator_strip_schema' => 1, ); The 'public' schema was stripped off of the generated class files, and the keys are now defined in the .ini file. For example... [vendors] vid = 129 vcode = 2 vname = 2 keep = 1 [vendors__keys] vid = K So things are looking much better. I have a few questions. 1) Is this not what one would consider to be the default expected behavior for using the generator on a pgsql database? If so, then why not make this the default option for the generator under those conditions? 2) Is this option 'generator_strip_schema' ONLY necessary for generation, and will it have any effects if left in, or removed from, the options array during normal (production) use? Also, could the end user documentation 'Configuration Options' be updated in order to help other pgsql users of this package? -- R. Lee Wixson ThoughtProcess.net