<link linkend="ddl-rowsecurity">row-level security</link> enabled, then
    by default, the row-level security policies of the view owner are applied,
    and access to any additional relations referred to by those policies is
    determined by the permissions of the view owner.  However, if the view has
    <literal>security_invoker</literal> set to <literal>true</literal>, then
    the policies and permissions of the invoking user are used instead, as if
    the base relations had been referenced directly from the query using the
    view.
   </para>

   <para>
    Functions called in the view are treated the same as if they had been
    called directly from the query using the view.  Therefore, the user of
    a view must have permissions to call all functions used by the view.
    Functions in the view are executed with the privileges of the user
    executing the query or the function owner, depending on whether the
    functions are defined as <literal>SECURITY INVOKER</literal> or
    <literal>SECURITY DEFINER</literal>.  Thus, for example, calling
    <literal>CURRENT_USER</literal> directly in a view will always return the
    invoking user, not the view owner.  This is not affected by the view's
    <literal>security_invoker</literal> setting, and so a view with
    <literal>security_invoker</literal> set to <literal>false</literal> is
    <emphasis>not</emphasis> equivalent to a
    <literal>SECURITY DEFINER</literal> function and those concepts should not
    be confused.
   </para>

   <para>
    The user creating or replacing a view must have <literal>USAGE</literal>
    privileges on any schemas referred to in the view query, in order to look
    up the referenced objects in those schemas.  Note, however, that this
    lookup only happens when the view is created or replaced.  Therefore, the
    user of the view only requires the <literal>USAGE</literal> privilege on
    the schema containing the view, not on the schemas referred to in the view
    query, even for a security invoker view.
   </para>

   <para>
    When <command>CREATE OR REPLACE VIEW</command> is used on an existing
    view, only the view's defining SELECT rule, plus any
    <literal>WITH ( ... )</literal> parameters and its
    <literal>CHECK OPTION</literal> are changed.
    Other view properties, including ownership, permissions, and non-SELECT
    rules, remain unchanged.  You must own the view
    to replace it (this includes being a member of the owning role).
   </para>

  <refsect2 id="sql-createview-updatable-views">
   <title>Updatable Views</title>

   <indexterm zone="sql-createview-updatable-views">
    <primary>updatable views</primary>
   </indexterm>

   <para>
    Simple views are automatically updatable: the system will allow
    <command>INSERT</command>, <command>UPDATE</command>,
    <command>DELETE</command>, and <command>MERGE</command> statements
    to be used on the view in the same way as on a regular table.  A view is
    automatically updatable if it satisfies all of the following conditions:

    <itemizedlist>
     <listitem>
      <para>
       The view must have exactly one entry in its <literal>FROM</literal> list,
       which must be a table or another updatable view.
      </para>
     </listitem>

     <listitem>
      <para>
       The view definition must not contain <literal>WITH</literal>,
       <literal>DISTINCT</literal>, <literal>GROUP BY</literal>, <literal>HAVING</literal>,
       <literal>LIMIT</literal>, or <literal>OFFSET</literal> clauses at the top level.
      </para>
     </listitem>

     <listitem>
      <para>
       The view definition must not contain set operations (<literal>UNION</literal>,
       <literal>INTERSECT</literal> or <literal>EXCEPT</literal>) at the top level.
      </para>
     </listitem>

     <listitem>
      <para>
       The view's select list must not contain any aggregates, window functions
       or set-returning functions.
      </para>
     </listitem>
    </itemizedlist>