Re: [v9.2] sepgsql's DROP Permission checks - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [v9.2] sepgsql's DROP Permission checks
Date
Msg-id CA+TgmoYbYhzE4qdDM9ahoJmQf4RRRt9F2F-qZUORSQqC7e2bWg@mail.gmail.com
Whole thread Raw
In response to Re: [v9.2] sepgsql's DROP Permission checks  (Kohei KaiGai <kaigai@kaigai.gr.jp>)
Responses Re: [v9.2] sepgsql's DROP Permission checks  (Kohei KaiGai <kaigai@kaigai.gr.jp>)
List pgsql-hackers
On Sun, Jan 22, 2012 at 9:54 AM, Kohei KaiGai <kaigai@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

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: GUC_REPORT for protocol tunables was: Re: Optimize binary serialization format of arrays with fixed size elements
Next
From: Jeff Janes
Date:
Subject: Re: some longer, larger pgbench tests with various performance-related patches