Good analysis, Tom. Here is a patch for pgaccess that gets the system
oid the _new_ way. Funny I studied the pg_proc query but never looked
above it to see that the system oid check was already there and this is
a new bug.
I don't see any code that does version-specific stuff in pgaccess, so I
guess this will have to be only for > 7.1 backends. There must be lots
of version-specific pgaccess stuff so it only works with the current
release.
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > I have attached a patch that you suggested. I see the problem is that
> > _every_ function is listed. You solution is to list only functions you
> > own.
>
> This is certainly not a correct solution.
>
> The problem is that pgaccess has not been updated to know the correct
> way of determining the last system OID in 7.1 (OID of template1 is not
> the thing to look at anymore). It should do something similar to what
> pg_dump does --- see the two alternative implementations of
> findLastBuiltinOid in pg_dump.c.
>
> regards, tom lane
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
? pgaccess
Index: lib/mainlib.tcl
===================================================================
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/bin/pgaccess/lib/mainlib.tcl,v
retrieving revision 1.7
diff -c -r1.7 mainlib.tcl
*** lib/mainlib.tcl 2001/02/07 21:30:12 1.7
--- lib/mainlib.tcl 2001/05/30 16:50:15
***************
*** 109,115 ****
set maxim 16384
setCursor CLOCK
catch {
! wpg_select $CurrentDB "select oid from pg_database where datname='template1'" rec {
set maxim $rec(oid)
}
}
--- 109,115 ----
set maxim 16384
setCursor CLOCK
catch {
! wpg_select $CurrentDB "select datlastsysoid from pg_database where datname='" $PgAcVar(opendb,dbname) "'" rec
{
set maxim $rec(oid)
}
}
