Doh. Quite right. Well, the 7.0 initdb creates pg_indexes as the last thing it does. (Even though there are higher oids in pg_attribute, pg_rewrite and pg_description.), so how about the attached patch?


Seems reasonable, but the patch ought to fix the comment just above,
preferably with the above observation that this is correct by
examination of the now-frozen 7.0 initdb code ...

Attached.


Chris

Index: pg_dump.c
===================================================================
RCS file: /projects/cvsroot/pgsql-server/src/bin/pg_dump/pg_dump.c,v
retrieving revision 1.353
diff -c -r1.353 pg_dump.c
*** pg_dump.c   8 Oct 2003 03:52:32 -0000       1.353
--- pg_dump.c   21 Oct 2003 01:17:58 -0000
***************
*** 5864,5870 ****
  /*
   * findLastBuiltInOid -
   * find the last built in oid
!  * we do this by looking up the oid of 'template1' in pg_database,
   * this is probably not foolproof but comes close
  */
  
--- 5864,5871 ----
  /*
   * findLastBuiltInOid -
   * find the last built in oid
!  * we do this by assuming that the last thing the now-frozen 7.0.x initdb  
!  * does is to create the pg_indexes view.
   * this is probably not foolproof but comes close
  */
  
***************
*** 5876,5882 ****
        int                     last_oid;
  
        res = PQexec(g_conn,
!                         "SELECT oid from pg_database where datname = 'template1'");
        if (res == NULL ||
                PQresultStatus(res) != PGRES_TUPLES_OK)
        {
--- 5877,5883 ----
        int                     last_oid;
  
        res = PQexec(g_conn,
!                         "SELECT oid FROM pg_class WHERE relname='pg_indexes'");
        if (res == NULL ||
                PQresultStatus(res) != PGRES_TUPLES_OK)
        {
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

               http://archives.postgresql.org

Reply via email to