On 12/31/15 19:06, Jim Nasby wrote: > Those columns are there to tell you what *kind* of objects are involved in > the dependency. For example, a function will have two entries. classid will > be 1255 (pg_proc) for both of them. refclassid will be 2612 (pg_language) > for one and 2615 (pg_namespace) for the other.
Right, well, the classid for a function is 1255 because 1255 is the Oid of a row in pg_class ... and that row happens to describe a relation named pg_proc, which is the relation in which you find functions. Now, if you go to that relation, and look for a row whose Oid is the objid part of the address, that row is the specific function you're looking for. So, if I give you the object address (1255, 1397, 0), these are the two steps you will use to learn what I'm talking about: SELECT relname FROM pg_class WHERE oid = 1255; --------- pg_proc SELECT * FROM pg_proc WHERE oid = 1397; -----+-...-+---------+-... abs | ... | int4abs | ... Ok, now what if I give you the object address (17001, 17270, 0) ? Of course, these oids aren't predefined so they won't be the same from one database to the next. But in the test database I'm logged in to right now, you can follow the very same two steps: SELECT relname FROM pg_class WHERE oid = 17001; relname ---------------- jar_repository SELECT * FROM jar_repository WHERE oid = 17270; jarid | jarname | jarowner | jarmanifest | ... -------+----------+----------+-------------------+-... 2 | examples | chap | Manifest-Versio...| ... Nothing new has happened here. The algorithm is unchanged. The object address (17001, 17270, 0) means "the PL/Java examples jar", in exactly the same way that (1255, 1397, 0) means "the int4abs function". (I had to cheat a little and ALTER TABLE jar_repository SET WITH OIDS because in stock PL/Java it doesn't have them, but that was easy enough.) The only thing that stops me at present from passing an ObjectAddress like (17001, 17270, 0) to recordDependencyOn(...) is that the *documentation* says the classid can't be the Oid of just *any* old row in pg_class, is has to be the oid of a row in pg_class *that describes a system catalog*. As far as the actual code, if I tried that right now I don't actually think anything would stop me from recording the dependency. Things would break when I tried to drop something though, because getObjectClass() would be called on my dependency, not recognize that Oid among the ones it knows about, and throw an error. How about having a default case there, saying "hmm, jar_repository, not a table I recognize, it must belong to some extension. Well, I'll just go and delete its row with oid = 17270 anyway, and let the extension that owns it handle the DELETE trigger if any, and we're good to go." ? To a first approximation, it's as easy as that. All the rest of my earlier message was about proposing rules to enforce reasonable restrictions so the dependency jazz isn't opened up to every old user table with triggers calling arbitrary code to get all tangled up in PostgreSQL's DROP internals, but it is opened up in a controlled way to extensions that create new classes of things to be managed. -Chap -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers