Problem: Generating DataObjects for Views with Postgres

Hi there, I was thinking, hey, I'm using Postgres now, so let's make use of this nifty feature called views. So, I configured my DataObject.ini with build_views=1 and ran createTables. Imagine my surprise: [db_error: message="DB Error: insufficient data supplied" code=-20 mode=return level=notice prefix="" info="SELECT viewname FROM pg_views [nativecode=ERROR: relation "views" does not exist]"] Right. Okay, so it does a query on pg_views and Postgres complains (and rightfully so) that "views" doesn't exist. But I queried pg_views, not views. What the...? So I took a look at the code. The DataObject Generator calls: $views = $__DB->getListOf('views'); In DB's pgsql.php (getSpecialQuery()) that translates to: return 'SELECT viewname FROM pg_views'; ...which is then used in DB_common with getCol(). So the query *is* actually correct. Digging through the PostgreSQL log, I found that this query is sent before all the table information is queried. And only after fetching all other table information, the bogus query is being sent... after finding that out, the reason finally hit me. So here's what happens: Basically, the generator first fetches the names of all tables, then fetches the names of all all views and adds them to the list of tables. Now, if you perform a SELECT * FROM pg_views on Postgres, you'll find out, that *all* views, even the internal ones from Postgres that aren't user-defined, are listet from *all* schemas that are in the current database. The first view in the list is called "views", which is part of the information_schema. Now, when you do a "normal" query and you don't specify a schema name, Postgres will always look into the default schema, which is "public". And as "views" is being returned as one of the available views (without the schema information) and the query says "SELECT * FROM views", Postgres correctly throws an error, as it cannot find that view in the public schema. The question is: Can this be solved in a generic way? Technically, DB would need to return the view names including schema information (for BC with other drivers, it would need to return only one column, so in this case it would have needed to return "information_schema.views") and the DataObject Generator would need to treat views separately from "real" tables, or just omitting all view names that do not start with "public.". Comments? Opinions? Anyone had this problem before? CU Markus