Skip site navigation (1) Skip section navigation (2)

Re: [v9.2] sepgsql's DROP Permission checks

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>
Cc: PgHacker <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [v9.2] sepgsql's DROP Permission checks
Date: 2012-01-25 16:57:22
Message-ID: CA+TgmoYbYhzE4qdDM9ahoJmQf4RRRt9F2F-qZUORSQqC7e2bWg@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Sun, Jan 22, 2012 at 9:54 AM, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)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: perform-deletion-internal.patch
Description: application/octet-stream (12.8 KB)

In response to

Responses

pgsql-hackers by date

Next:From: hubert depesz lubaczewskiDate: 2012-01-25 16:57:50
Subject: Re: Why extract( ... from timestamp ) is not immutable?
Previous:From: Adrian KlaverDate: 2012-01-25 16:54:44
Subject: Re: Why extract( ... from timestamp ) is not immutable?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group