mirror of
https://github.com/postgres/postgres.git
synced 2025-08-30 06:01:21 +03:00
Support automatically-updatable views.
This patch makes "simple" views automatically updatable, without the need to create either INSTEAD OF triggers or INSTEAD rules. "Simple" views are those classified as updatable according to SQL-92 rules. The rewriter transforms INSERT/UPDATE/DELETE commands on such views directly into an equivalent command on the underlying table, which will generally have noticeably better performance than is possible with either triggers or user-written rules. A view that has INSTEAD OF triggers or INSTEAD rules continues to operate the same as before. For the moment, security_barrier views are not considered simple. Also, we do not support WITH CHECK OPTION. These features may be added in future. Dean Rasheed, reviewed by Amit Kapila
This commit is contained in:
@@ -45,10 +45,10 @@ CREATE [ OR REPLACE ] RULE <replaceable class="parameter">name</replaceable> AS
|
||||
additional commands to be executed when a given command on a given
|
||||
table is executed. Alternatively, an <literal>INSTEAD</literal>
|
||||
rule can replace a given command by another, or cause a command
|
||||
not to be executed at all. Rules are used to implement table
|
||||
not to be executed at all. Rules are used to implement SQL
|
||||
views as well. It is important to realize that a rule is really
|
||||
a command transformation mechanism, or command macro. The
|
||||
transformation happens before the execution of the commands starts.
|
||||
transformation happens before the execution of the command starts.
|
||||
If you actually want an operation that fires independently for each
|
||||
physical row, you probably want to use a trigger, not a rule.
|
||||
More information about the rules system is in <xref linkend="rules">.
|
||||
@@ -73,13 +73,11 @@ CREATE [ OR REPLACE ] RULE <replaceable class="parameter">name</replaceable> AS
|
||||
sufficient for your purposes) to replace update actions on the view
|
||||
with appropriate updates on other tables. If you want to support
|
||||
<command>INSERT RETURNING</> and so on, then be sure to put a suitable
|
||||
<literal>RETURNING</> clause into each of these rules. Alternatively,
|
||||
an updatable view can be implemented using <literal>INSTEAD OF</>
|
||||
triggers (see <xref linkend="sql-createtrigger">).
|
||||
<literal>RETURNING</> clause into each of these rules.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
There is a catch if you try to use conditional rules for view
|
||||
There is a catch if you try to use conditional rules for complex view
|
||||
updates: there <emphasis>must</> be an unconditional
|
||||
<literal>INSTEAD</literal> rule for each action you wish to allow
|
||||
on the view. If the rule is conditional, or is not
|
||||
@@ -95,6 +93,21 @@ CREATE [ OR REPLACE ] RULE <replaceable class="parameter">name</replaceable> AS
|
||||
<literal>INSTEAD NOTHING</literal> action. (This method does not
|
||||
currently work to support <literal>RETURNING</> queries, however.)
|
||||
</para>
|
||||
|
||||
<note>
|
||||
<para>
|
||||
A view that is simple enough to be automatically updatable (see <xref
|
||||
linkend="sql-createview">) does not require a user-created rule in
|
||||
order to be updatable. While you can create an explicit rule anyway,
|
||||
the automatic update transformation will generally outperform an
|
||||
explicit rule.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Another alternative worth considering is to use <literal>INSTEAD OF</>
|
||||
triggers (see <xref linkend="sql-createtrigger">) in place of rules.
|
||||
</para>
|
||||
</note>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
|
Reference in New Issue
Block a user