update.php fails after install in pgsql schema other than "public"

PHP version 5.3.10
Drupal 7.12
Postgres 9.1.2

Drupal 7 installs successfully but then update.php fails with the following error:

PDOException: SQLSTATE[42P07]: Duplicate table: 7 ERROR: relation
"registry" already exists: CREATE TABLE {registry} ( name varchar(255)
NOT NULL default '', type varchar(9) NOT NULL default '', filename
varchar(255) NOT NULL default '', module varchar(255) NOT NULL default
'', weight int NOT NULL default 0, PRIMARY KEY (name, type) ); Array ( )
in db_create_table() (line 2688 of
/var/www/html/includes/database/database.inc).

This error occurs when I install D7 in a non-default PostgreSQL schema (let's call it "privat". If I drop that schema and just let D7 install in the public schema in the same database (with the same user) then D7 will not only installs but update.php will then then run without error.

From a best-practice standpoint, though, I think we'd want to run in non-public schema.

While I was able to get D7 installed in the schema named "privat", that was not without challenges. I followed a number of directions including addition of $db_prefix = 'privat'; to settings.php but even then had to manually edit /includes/database/pgsql/schema.inc to replace 'public' with 'privat' as noted in this thread:

http://drupal.org/node/1060476

Supporting SQL is like so, with user and schema both named "privat" for this example:

CREATE DATABASE drupal;
CREATE ROLE privat LOGIN ENCRYPTED PASSWORD '*********' NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE;
\c drupal
CREATE SCHEMA privat AUTHORIZATION privat;
GRANT ALL PRIVILEGES ON SCHEMA privat TO privat;
GRANT ALL PRIVILEGES ON DATABASE drupal TO privat;

Since this starts working as soon as I revert to the public schema, this would appear to be a problem with the D7 core PostgreSQL component.

I saw a few threads regarding errors that were somewhat similar, for example:

http://drupal.org/node/1013034

For the heck of it, I put that patch in to see if a collateral miracle would occur, but no joy.

I'd be interested in any workarounds or insights anyone can offer. For a number of reasons (some other applications) we are looking to standardize on PosgreSQL, but would like to feel that we have it configured as well as is possible.

Jim