Mariel Cherkassky <mariel.cherkassky@gmail.com> 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