Обсуждение: pgAdmin: blank header in the "Edit Data" window if table OID changes

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.

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.

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'::regclassORDER BY attnum;
 
But I suppose that is slower.

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.

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

-- 
------------------------------------------------------------------------
|  Steven Elliott  |  http://selliott.org  |  selliott4@austin.rr.com  |
------------------------------------------------------------------------

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