Tom Lane wrote:
> I think a correct solution probably requires making a list of all
> objects to delete by scanning pg_shdepend and then starting to
> delete 'em, using the list as "oktodelete" context similar to the
> way that dependency.c handles auto/internal objects.
What I'm considering is this: scan pg_shdepend looking for objects to
delete, and save them into a list; but each time we find one, we also
find objects that depend on it. Those dependent objects should be
ignored; but we should also remove from the list of objects to delete,
any dependent object that we added in a previous iteration of the
pg_shdepend scan. A subtlety is that if we see that an object from the
scan is in the ignored list, we need not find dependent objects nor add
it to the to-delete list.
In pseudo-code it would be something like this:
ObjectAddresses objects-to-delete = empty
ObjectAddresses objects-ignored = empty
scan pg_shdepend for objects depending on the user;
for (object) in scan
if (object is not in objects-ignored)
ObjectAddresses dependent-objects = empty
add object to objects-to-delete
dependent-objects = findAutoDeletableObjects(object)
add dependent-objects to objects-ignored
for (object2) in objects-to-delete
if (object2 is in objects-ignored)
remove object2 from objects-to-delete
add object2 fo objects-ignored
for (object) in objects-to-delete
performDeletion(object)
This has a nasty looking O(n^2) behavior, but I don't see anything
better.
Comments?
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
