Transactional DDL, but not Serializable

Greetings,
 We have a curious situation, consider this:
 Process 1:   BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE;CRETE TABLE table1 (i integer);INSERT INTO table1 VALUES
(13);
 Process 2:   BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE;CREATE TABLE table2 (i integer);INSERT INTO table2 VALUES
(123);COMMIT;
 Process 1:   SELECT * FROM pg_class WHERE relname = 'table2'; -- no rows returnedSELECT * FROM table2; -- works?!  but
atleast no records returnedINSERT INTO table2 VALUES (456);   -- also works..  now we have a tuple in the table which
appearsto  -- have been added before the table existed..COMMIT; 
 This happens, of course, because we use SysCache to look up table names to Oids and that uses SnapshotNow.  In my
view,this violates the basic principle of least suprise and means that while we have transaction DDL, but it's not
reallyserializable (no, I don't particularly care about that). 
 What I do worry about is that the bulk load discussion going on could be shot down because of this.  We won't let the
earliertransaction see any records in the table today because those tuples have an xmin later, but if we were to insert
thosetuples with the frozen XID (as I proposed in the other thread) then they'd be visible. 
 I don't believe fixing this would be terribly difficult and, I believe, would be similar to what we've done else where
(eg:with indexes)- basically, add a column to pg_class with the 'createdxmin' and then compare that against our
transactionwhenever we're doing table lookups. 
 Thoughts?
     Thanks,
    Stephen