Re: [v9.3] OAT_POST_ALTER object access hooks

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PgHacker <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [v9.3] OAT_POST_ALTER object access hooks
Date: 2013-03-07 02:10:49
Message-ID: CA+TgmoZ4DK_fvthewXvtBrNQhrpzsk8ZbW7T+dYZa98M_Cumqg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Jan 27, 2013 at 1:55 AM, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ian Pilcher 2013-03-07 03:16:19 Trust intermediate CA for client certificates
Previous Message Robert Haas 2013-03-07 01:53:47 Re: [v9.3] OAT_POST_ALTER object access hooks