mirror of
https://github.com/postgres/postgres.git
synced 2025-07-31 22:04:40 +03:00
Add more infinite recursion detection while locking a view.
Also add regression test cases for detecting infinite recursion in locking view tests. Some document enhancements. Patch by Yugo Nagata.
This commit is contained in:
@ -46,8 +46,8 @@ 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.
|
||||
When a view is locked, all relations appearing in the view definition
|
||||
query are also locked recursively with the same lock mode.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -173,6 +173,13 @@ LOCK [ TABLE ] [ ONLY ] <replaceable class="parameter">name</replaceable> [ * ]
|
||||
or <literal>TRUNCATE</literal> privileges.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The user performing the lock on the view must have the corresponding privilege
|
||||
on the view. In addition the view's owner must have the relevant privileges on
|
||||
the underlying base relations, but the user performing the lock does
|
||||
not need any permissions on the underlying base relations.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<command>LOCK TABLE</command> is useless outside a transaction block: the lock
|
||||
would remain held only to the completion of the statement. Therefore
|
||||
|
Reference in New Issue
Block a user