This finishes a task we left undone in commit
f1ad067fc, by extending
the delete-in-descending-OID-order rule to deletions triggered by
DROP OWNED BY. We've coped with machine-dependent deletion orders
one time too many, and the new issues caused by Peter G's recent
nbtree hacking seem like the last straw.
Discussion: https://postgr.es/m/E1h6eep-0001Mw-Vd@gemulon.postgresql.org
behavior);
}
+/*
+ * Sort the items in an ObjectAddresses array.
+ *
+ * The major sort key is OID-descending, so that newer objects will be listed
+ * first in most cases. This is primarily useful for ensuring stable outputs
+ * from regression tests; it's not recommended if the order of the objects is
+ * determined by user input, such as the order of targets in a DROP command.
+ */
+void
+sort_object_addresses(ObjectAddresses *addrs)
+{
+ if (addrs->numrefs > 1)
+ qsort((void *) addrs->refs, addrs->numrefs,
+ sizeof(ObjectAddress),
+ object_address_comparator);
+}
+
/*
* Clean up when done with an ObjectAddresses array.
*/
systable_endscan(scan);
}
+ /*
+ * For stability of deletion-report ordering, sort the objects into
+ * approximate reverse creation order before deletion. (This might also
+ * make the deletion go a bit faster, since there's less chance of having
+ * to rearrange the objects due to dependencies.)
+ */
+ sort_object_addresses(deleteobjs);
+
/* the dependency mechanism does the actual work */
performMultipleDeletions(deleteobjs, behavior, 0);
ObjectAddresses *referenced,
DependencyType behavior);
+extern void sort_object_addresses(ObjectAddresses *addrs);
+
extern void free_object_addresses(ObjectAddresses *addrs);
/* in pg_depend.c */