Re: pg_depend
От | Tom Lane |
---|---|
Тема | Re: pg_depend |
Дата | |
Msg-id | 21673.995325784@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pg_depend (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: pg_depend
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: