I noticed that pg_attribute has rows with the same OID! You can
verify this by running.
# select count(oid),oid from pg_attribute group by oid having
count(oid) > 1;
We see that these duplicate OIDs appear to happen when
pg_attibute rows are inserted for indexes and primary keys.
select relname, attname
from pg_attribute , pg_class
where attrelid = pg_class.oid and
pg_attribute.oid in (select oid
from pg_attribute
group by oid
having count(oid) > 1);
I see:
relname
| attname
---------------------------------+--------------
pg_aggregate_name_type_index
| aggname
pg_aggregate_name_type_index
| aggbasetype
pg_amop_opid_index
| amopclaid
pg_amop_opid_index
| amopopr
pg_amop_opid_index
| amopid
pg_amop_strategy_index
| amopid
pg_amop_strategy_index
| amopclaid
pg_amop_strategy_index
| amopstrategy
pg_attribute_relid_attnam_index
| attrelid
pg_attribute_relid_attnam_index
| attname
pg_attribute_relid_attnum_index
| attrelid
pg_attribute_relid_attnum_index
| attnum
pg_inherits_relid_seqno_index
| inhrelid
pg_inherits_relid_seqno_index
| inhseqno
pg_largeobject_loid_pn_index
| loid
pg_largeobject_loid_pn_index
| pageno
pg_listener_pid_relname_index
| listenerpid
pg_listener_pid_relname_index
| relname
pg_operator_oprname_l_r_k_index
| oprname
pg_operator_oprname_l_r_k_index
| oprleft
pg_operator_oprname_l_r_k_index
| oprright
pg_operator_oprname_l_r_k_index
| oprkind
pg_proc_proname_narg_type_index
| proname
pg_proc_proname_narg_type_index
| pronargs
pg_proc_proname_narg_type_index
| proargtypes
pg_statistic_relid_att_index
| starelid
pg_statistic_relid_att_index
| staattnum
primarytest2_pkey
| col1
primarytest2_pkey
| col2
(29 rows)
What do people think about this issue? It doesn't seem to have
major consequences now, but it should probably be fixed? When
system tables have referential integrity enforced, then it will be
an
issue. Can this be put on the TODO list?
Regards,
Joe Mitchell
Great Bridge LLC
