Peter Eisentraut <peter_e@gmx.net> writes:
> You look at pg_depend and see that objects 145928, 264792, and 1893723
> depend on it. Great, what do you do now?
>> I believe someone else previously suggested this:
>> drop <type> object [RESTRICT | CASCADE]
>> to make use of dependency info.
> That was me. The point, however, was, given object id 145928, how the
> heck to you know what table this comes from?
Even more to the point, what guarantee can we have that that OID even
defines a unique object at all? We have unique indexes that ensure
there are not two tables with the same OID, or two functions with the
same OID, etc --- but none that ensure uniqueness across system
catalogs.
The objects would need to be identified by two-part IDs, one part
specifying the object type and one giving its OID (which is known unique
within that type). Possibly object type would be best handled by giving
the OID of the system catalog containing the object's definition row.
In any case, looking at the type part would let users of the pg_depend
catalog figure out what they needed to do.
BTW, pg_description is broken because it assumes that OID alone is a
sufficient identifier ... but since it's such a noncritical function,
I haven't gotten too excited about it.
regards, tom lane