Dimitri Fontaine <dimi...@2ndquadrant.fr> writes:
> There's a difference between "it's not the way I would have done it" and
> "the author didn't think about what he's doing". That's also the reason
> why it's very hard to justify sending a polished enough patch as a non
> commiter.
> And then this patch is like the next one in a long series that is
> lasting for about 2 years now, and spliting it is just more work for
> everybody, and then you take the risk that the next commiter who looks
> at the patch prefers to see a complete enough view of the goal you're
> trying to reach.
What was discussed at the last dev meeting was assigning a committer to
each large patch to start with, which would reduce the risk of the
goalposts moving that way. It seems to me that Robert's at least
unofficially taken that role for event triggers. You should be happy,
because if I were reviewing it I'd likely bounce the whole thing.
I'm not convinced this will *ever* be a stable feature that doesn't
create more problems than it fixes.
> What I think you're missing here is the proposal flying around to have
> drop operation get back to ProcessUtility so that C hooks and event
> triggers both can have at it.
I've seen no such proposal, and it seems like a nonstarter just from the
idea. dependency.c doesn't have a syntax tree to describe each object
that it finds to drop; creating one, and then doing a lookup to re-find
the object, is just going to make drops hugely slower and buggier. Not
to mention the large amount of code that would have to be added and
maintained. Not to mention that the objects dependency.c works with
aren't necessarily all that interesting from the user's level --- for
instance, do you really want to see each column default expression
dropped individually? Not to mention that the permissions
considerations are different from a standalone DROP.
The bigger picture there is that it's taken us years, and multiple major
iterations, to get cascaded drops to work properly and reliably. I'm
disinclined to rip that code open and rewrite it completely; let alone
add hooks that might inject random operations at any point in the
process.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
