On Sun, Jan 22, 2012 at 9:54 AM, Kohei KaiGai <kai...@kaigai.gr.jp> wrote: > I tried to implement based on the idea to call object-access-hook with > flag; that > informs extensions contexts of objects being removed. > Because I missed DROP_RESTRICT and DROP_CASCADE are enum type, > this patch added performInternalDeletion() instead of OR-masked DROP_INTERNAL. > All its difference from performDeletion() is a flag (OAT_DROP_FLAGS_INTERNAL) > shall be delivered to extension module. I replaced several performDeletion() > by > performInternalDeletion() that clean-up objects due to internal stuff. > > How about this approach?
I generally agree with this line of attack, but I think you've failed to find all the cases where a drop should be considered internal, and I'd rather add a new parameter to an existing function than define a new one that someone might accidentally fail to use in some place where it's needed. Here's a cut-down patch that *just* adds a PERFORM_DELETE_INTERNAL flag, plus some related comment additions. If this looks reasonable to you, I'll commit it and then we can work out the remaining details. Since sepgsql doesn't seem to need the DropBehavior, I'm inclined to say we shouldn't go to any extra work to pass it just now. We can always add that later if some other client needs it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
perform-deletion-internal.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
