Re: pgAdmin: blank header in the "Edit Data" window if table OID changes

Le 17/04/2011 07:48, Steven Elliott a écrit :
> I noticed that the headers (column names and types at the top of the
> table) are blank in the "Edit Data" window (displayed if "View the data
> in the selected object" button is pressed) if the table OID changes
> while pgAdmin is running.  I have this problem (changed table OID) when
> I recreate a database from a dump while pgAdmin is running.
> 

Yeah, this is an issue we would like to fix. There is already a ticket
on it (http://code.pgadmin.org/trac/ticket/44). Ashesh was supposed to
work on it, but I guess he has already too much work :)

> Turning on query logging reveals that the issue is that pgAdmin is using
> cached OIDs.  Refreshing the table (pressing F5 while the table is
> selected) fixes the problem.  Refreshing also causes pgAdmin to use the
> updated OID.
> 

That's true.

> There are various queries involved in displaying the "Edit Data" window,
> but consider this one:
>   SELECT attisdropped 
>   FROM pg_attribute 
>   WHERE attnum > 0 AND attrelid=36214::oid
>   ORDER BY attnum;
> In this case "36214" is the cached and possibly stale table OID.  If the
> OID is stale then the above returns zero rows, so one possibility is to
> reload the table OIDs if the this query returns less rows than expected.
> Another is to use the table name in each query, so the above becomes (if
> the table is named "my-table"):
>   SELECT attisdropped 
>   FROM pg_attribute 
>   WHERE attnum > 0 AND attrelid='my-table'::regclass
>   ORDER BY attnum;
> But I suppose that is slower.
> 

Slower and not less exposed to bugs. What happened if you rename the
table? with OID it still works.

> I've seen this problem on Fedora 13 i686 as well as Fedora 14 x86_64.
> I've seen it with pgAdmin version 1.10.5 as well as latest GIT as of
> 2011-04-17.
> 

Yeah, this is a long lasting issue.

> Let me know if there is anything else I can tell you that would be
> helpful.
> 

That's already a really good bug report.


-- 
Guillaumehttp://www.postgresql.frhttp://dalibo.com