Re: [v9.3] OAT_POST_ALTER object access hooks - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [v9.3] OAT_POST_ALTER object access hooks
Date
Msg-id CA+TgmoZ4DK_fvthewXvtBrNQhrpzsk8ZbW7T+dYZa98M_Cumqg@mail.gmail.com
Whole thread Raw
In response to Re: [v9.3] OAT_POST_ALTER object access hooks  (Kohei KaiGai <kaigai@kaigai.gr.jp>)
Responses Re: [v9.3] OAT_POST_ALTER object access hooks
List pgsql-hackers
On Sun, Jan 27, 2013 at 1:55 AM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:
> The part-2 patch adds new OAT_POST_ALTER event type, and
> its relevant permission checks on contrib/sepgsql.

This documentation hunk is unclear:

+    On <xref linkend="sql-createfunction">, <literal>install</> permission
+    will be checked if <literal>leakproof</> attribute was given, not only
+    <literal>create</> on the new function.

Based on previous experience reading your patches, I'm guessing that
what you actually mean is that both things are checked, but the
wording doesn't make that clear.  Also, if permissions are now checked
on functions, doesn't the previous sentence need an update?

+    In addition, <literal>add_name</> and <literal>remove_name</> permission
+    will be checked towards relevant schema when we try to rename or set
+    new schema on the altered object.

Suggest: In addition, <literal>remove_name</> and <literal>add_name</>
will be checked on the old and new schemas, respectively, when an
object is moved to a new schema.

+    A few additional checks are applied depending on object types.

For certain object types, additional checks are performed.

+    On <xref linkend="sql-alterfunction">, <literal>install</> permission
+    will be checked if <literal>leakproof</> attribute was turned on, not
+    only <literal>setattr</> on the new function.

This is a near-duplicate of the previous hunk and suffers from the
same awkwardness.

+ * is_internal: TRUE if constraint is constructed unless user's intention

I dunno what this means.  What's the difference between an internal
constraint and a non-internal constraint, and why do we need that
distinction?  This seems to percolate to a lot of places; I'd rather
not do that without a real good reason.

+       /* XXX - should be checked at caller side */

XXX should be used only for things that really ought to be revisited
and changed.  See the wording I used in the just-committed part 1
patch.

+#include "catalog/objectaccess.h"

This is the only hunk in collationcmds.c, hence presumably not needed.

+               /* Post create hook of this access method operator */
+               InvokeObjectPostCreateHook(AccessMethodOperatorRelationId,
+                                                                  entryoid, 0);

I suggest uniformly adding a blank line before each of these hunks,
rather than adding it for some and not others.  I think, though, that
we could probably ditch the comments throughout.  They don't add
anything, really.

@@ -3330,7 +3342,6 @@ ATExecCmd(List **wqueue, AlteredTableInfo *tab,
Relation rel,                        */                       break;               case AT_SetTableSpace:  /* SET
TABLESPACE*/
 
-                       /*                        * Nothing to do here; Phase 3 does the work
*/

Spurious whitespace hunk.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Re: proposal 9.4 plpgsql: allows access to call stack from GET DIAGNOSTICS statement
Next
From: Greg Smith
Date:
Subject: Re: Enabling Checksums