Tom Lane <tgl@sss.pgh.pa.us> writes:
> I might be forgetting something, but doesn't dependency.c work by first
> constructing a list of all the objects it's going to drop, and only then
> dropping them? Could we inject a "pre deletion" event trigger call at
> the point where the list is completed?
What happens if the event trigger itself deletes objects? From the list?
Then we have to redo all the preparatory steps, and I don't think we
agreed on a way to do it. Plus, as we seem to be chasing minimal set of
features per patch, I would think that getting the list of Objects OIDs
that are already dropped is a well enough defined set of minimal feature
for this very patch, that we will be in a position to extend later given
some time.
I still think we should think about the set of information we're going
to be publishing first, because without publishing some more all we're
doing here is moot anyway. Also, for most cases that I can think of,
it's not a problem for the dropped object to not exist anymore in the
catalogs by the time you get the information, if you get the object's
name and schema and maybe some other properties.
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
