|
1 | 1 | <!-- |
2 | | -$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_rule.sgml,v 1.28 2001/10/09 18:46:00 petere Exp $ |
| 2 | +$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_rule.sgml,v 1.29 2001/11/06 23:54:32 tgl Exp $ |
3 | 3 | Postgres documentation |
4 | 4 | --> |
5 | 5 |
|
@@ -196,21 +196,55 @@ CREATE |
196 | 196 |
|
197 | 197 | <refsect2 id="R2-SQL-CREATERULE-3"> |
198 | 198 | <refsect2info> |
199 | | - <date>2001-01-05</date> |
| 199 | + <date>2001-11-06</date> |
200 | 200 | </refsect2info> |
201 | 201 | <title> |
202 | | -Notes |
| 202 | +Rules and Views |
203 | 203 | </title> |
204 | 204 | <para> |
205 | 205 | Presently, ON SELECT rules must be unconditional INSTEAD rules and must |
206 | 206 | have actions that consist of a single SELECT query. Thus, an ON SELECT |
207 | 207 | rule effectively turns the object table into a view, whose visible |
208 | 208 | contents are the rows returned by the rule's SELECT query rather than |
209 | 209 | whatever had been stored in the table (if anything). It is considered |
210 | | - better style to write a CREATE VIEW command than to create a table and |
211 | | - define an ON SELECT rule for it. |
| 210 | + better style to write a CREATE VIEW command than to create a real table |
| 211 | + and define an ON SELECT rule for it. |
| 212 | + </para> |
| 213 | + |
| 214 | + <para> |
| 215 | + <xref linkend="sql-createview"> creates a dummy table (with no underlying |
| 216 | + storage) and associates an ON SELECT rule with it. The system will not |
| 217 | + allow updates to the view, since it knows there is no real table there. |
| 218 | + You can create the |
| 219 | + illusion of an updatable view by defining ON INSERT, ON UPDATE, and |
| 220 | + ON DELETE rules (or any subset of those that's sufficient |
| 221 | + for your purposes) to replace update actions on the view with |
| 222 | + appropriate updates on other tables. |
212 | 223 | </para> |
213 | 224 |
|
| 225 | + <para> |
| 226 | + There is a catch if you try to use conditional |
| 227 | + rules for view updates: there <emphasis>must</> be an unconditional |
| 228 | + INSTEAD rule for each action you wish to allow on the view. If the |
| 229 | + rule is conditional, or is not INSTEAD, then the system will still reject |
| 230 | + attempts to perform the update action, because it thinks it might end up |
| 231 | + trying to perform the action on the dummy table in some cases. |
| 232 | + If you want to |
| 233 | + handle all the useful cases in conditional rules, you can; just add an |
| 234 | + unconditional DO INSTEAD NOTHING rule to ensure that the system |
| 235 | + understands it will never be called on to update the dummy table. Then |
| 236 | + make the conditional rules non-INSTEAD; in the cases where they fire, |
| 237 | + they add to the default INSTEAD NOTHING action. |
| 238 | + </para> |
| 239 | + </refsect2> |
| 240 | + |
| 241 | + <refsect2 id="R2-SQL-CREATERULE-4"> |
| 242 | + <refsect2info> |
| 243 | + <date>2001-01-05</date> |
| 244 | + </refsect2info> |
| 245 | + <title> |
| 246 | + Notes |
| 247 | + </title> |
214 | 248 | <para> |
215 | 249 | You must have rule definition access to a table in order |
216 | 250 | to define a rule on it. Use <command>GRANT</command> |
@@ -267,7 +301,7 @@ UPDATE mytable SET name = 'foo' WHERE id = 42; |
267 | 301 | Compatibility |
268 | 302 | </title> |
269 | 303 |
|
270 | | - <refsect2 id="R2-SQL-CREATERULE-4"> |
| 304 | + <refsect2 id="R2-SQL-CREATERULE-5"> |
271 | 305 | <refsect2info> |
272 | 306 | <date>1998-09-11</date> |
273 | 307 | </refsect2info> |
|