Mariel Cherkassky <mariel.cherkassky@xxxxxxxxx> writes: > seq_oid | classid | objid | objsubid | refclassid | refobjid | refobjsubid > | deptype > ---------+---------+-------+----------+------------+----------+-------------+--------- > 17188 | 1259 | 17188 | 0 | 1259 | 17190 | 1 > | a > 16566 | 2604 | 16566 | 0 | 1259 | 17190 | 1 > | a > 16704 | 2606 | 16704 | 0 | 1259 | 17190 | 3 > | a > 16704 | 2606 | 16704 | 0 | 1259 | 17190 | 5 > | a > 16704 | 2606 | 16704 | 0 | 1259 | 17190 | 4 > | a > (5 rows) Well, those entries with objid = 16566 and 16704 are not for sequences, because the classid is wrong: 2604 is pg_attrdef, and 2606 is pg_constraint, so the second row is for a default expression belonging to table 17190 column 1, and the rest are for some kind of constraint involving columns 3,4,5 (maybe a check constraint?) In itself there's nothing wrong with these pg_depend entries, but it is odd that you have different objects with identical OIDs. Normally I'd only expect that to be possible once the OID counter has wrapped around ... but all these OIDs are small, which makes it seem unlikely that you've consumed enough OIDs to reach wraparound. Maybe you had a system crash, or did something weird with backup/recovery, causing the counter to get reset? Anyway, the short answer here is that neither objid nor refobjid should be considered sufficient to identify an object by themselves. You need to also check classid (refclassid), because OIDs are only guaranteed unique within a given system catalog. regards, tom lane
