From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp> |
Cc: | Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp>, robertmhaas(at)gmail(dot)com, thomas(dot)munro(at)enterprisedb(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [HACKERS] [PATCH] Lockable views |
Date: | 2018-03-30 00:26:36 |
Message-ID: | 20180330002636.fdomghnrsdcauuat@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2018-03-28 20:26:48 +0900, Yugo Nagata wrote:
> diff --git a/doc/src/sgml/ref/lock.sgml b/doc/src/sgml/ref/lock.sgml
> index b2c7203..96d477c 100644
> --- a/doc/src/sgml/ref/lock.sgml
> +++ b/doc/src/sgml/ref/lock.sgml
> @@ -46,6 +46,11 @@ LOCK [ TABLE ] [ ONLY ] <replaceable class="parameter">name</replaceable> [ * ]
> </para>
>
> <para>
> + When a view is specified to be locked, all relations appearing in the view
> + definition query are also locked recursively with the same lock mode.
> + </para>
Trailing space added. I'd remove "specified to be" from the sentence.
I think mentioning how this interacts with permissions would be a good
idea too. Given how operations use the view's owner to recurse, that's
not obvious. Should also explain what permissions are required to do the
operation on the view.
> @@ -86,15 +92,17 @@ RangeVarCallbackForLockTable(const RangeVar *rv, Oid relid, Oid oldrelid,
> return; /* woops, concurrently dropped; no permissions
> * check */
>
> - /* Currently, we only allow plain tables to be locked */
> - if (relkind != RELKIND_RELATION && relkind != RELKIND_PARTITIONED_TABLE)
> +
This newline looks spurious to me.
> /*
> + * Apply LOCK TABLE recursively over a view
> + *
> + * All tables and views appearing in the view definition query are locked
> + * recursively with the same lock mode.
> + */
> +
> +typedef struct
> +{
> + Oid root_reloid;
> + LOCKMODE lockmode;
> + bool nowait;
> + Oid viewowner;
> + Oid viewoid;
> +} LockViewRecurse_context;
Probably wouldn't hurt to pgindent the larger changes in the patch.
> +static bool
> +LockViewRecurse_walker(Node *node, LockViewRecurse_context *context)
> +{
> + if (node == NULL)
> + return false;
> +
> + if (IsA(node, Query))
> + {
> + Query *query = (Query *) node;
> + ListCell *rtable;
> +
> + foreach(rtable, query->rtable)
> + {
> + RangeTblEntry *rte = lfirst(rtable);
> + AclResult aclresult;
> +
> + Oid relid = rte->relid;
> + char relkind = rte->relkind;
> + char *relname = get_rel_name(relid);
> +
> + /* The OLD and NEW placeholder entries in the view's rtable are skipped. */
> + if (relid == context->viewoid &&
> + (!strcmp(rte->eref->aliasname, "old") || !strcmp(rte->eref->aliasname, "new")))
> + continue;
> +
> + /* Currently, we only allow plain tables or views to be locked. */
> + if (relkind != RELKIND_RELATION && relkind != RELKIND_PARTITIONED_TABLE &&
> + relkind != RELKIND_VIEW)
> + continue;
> +
> + /* Check infinite recursion in the view definition. */
> + if (relid == context->root_reloid)
> + ereport(ERROR,
> + (errcode(ERRCODE_INVALID_OBJECT_DEFINITION),
> + errmsg("infinite recursion detected in rules for relation \"%s\"",
> + get_rel_name(context->root_reloid))));
Hm, how can that happen? And if it can happen, why can it only happen
with the root relation?
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2018-03-30 00:34:54 | Re: Enhance pg_stat_wal_receiver view to display connected host |
Previous Message | Michael Paquier | 2018-03-30 00:24:14 | Re: Incorrect use of "an" and "a" in code comments and docs |