Re: pgadmin3 gets oid for schema wrong

Richard van den Berg wrote:
> I have this weird problem where pgadmin3 shows empty schema's 
> (tables(0), views(0), etc) while they are not empty at all. I upgraded 
> to the 1.2.0-0.0+beta2.0 debian package, but the problem persists.
> 
> Refreshing the schema causes the schema to disappear from the pgadmin3 
> tree. This is the query I see executed when doing the refresh:
> 
> SELECT CASE WHEN nspname LIKE 'pg\_temp\_%%' THEN 1
>             WHEN nsp.oid<17140 OR nspname like 'pg\_%' THEN 0
>             ELSE 2 END as nsptyp,
>        nsp.nspname, nsp.oid, pg_get_userbyid(nspowner) AS 
> namespaceowner, nspacl, description, has_schema_privilege(nsp.oid, 
> 'CREATE')
>  FROM pg_namespace nsp
>  LEFT OUTER JOIN pg_description des ON des.objoid=nsp.oid
> WHERE nsp.oid=2147483647::oid
> ORDER BY 1, nspname
> 
> I examined pg_namespace and the oid of the schema actually is 
> 2518196330. No wonder pgadmin3 thinks it's empty.

2147483647 is 0x7fffffff, i.e. LONG_MAX. Apparently, some function is 
cutting down the real oid value, which is 0x9618a06a.

Digging into the sources, I found two places where oids are converted 
using atol, which might be the offending function. I changed both to 
strtoul, and committed the changes to cvs.
Please check it (misc.cpp and pgSet.cpp affected) from source if 
possible or try Beta3, which we're be rolling quite soon an give us 
feedback because I don't have a test case.

Some remark:
Apparently your database consumes enormous amounts of oids, you're more 
than half way to a oid wrap which might cause undesired effects 
(duplicate oids). Your tables are probably all created WITH OIDS, which 
is still the default. You might consider dropping the oid columns, if 
you don't need them.

Regards,
Andreas