xref: /sqlite-3.40.0/test/e_update.test (revision b3366b99)
1# 2010 September 20
2#
3# The author disclaims copyright to this source code.  In place of
4# a legal notice, here is a blessing:
5#
6#    May you do good and not evil.
7#    May you find forgiveness for yourself and forgive others.
8#    May you share freely, never taking more than you give.
9#
10#***********************************************************************
11#
12# This file implements tests to verify that the "testable statements" in
13# the lang_update.html document are correct.
14#
15set testdir [file dirname $argv0]
16source $testdir/tester.tcl
17
18#--------------------
19# Test organization:
20#
21#   e_update-1.*: Test statements describing the workings of UPDATE statements.
22#
23#   e_update-2.*: Test the restrictions on the UPDATE statement syntax that
24#                 can be used within triggers.
25#
26#   e_update-3.*: Test the special LIMIT/OFFSET and ORDER BY clauses that can
27#                 be used with UPDATE when SQLite is compiled with
28#                 SQLITE_ENABLE_UPDATE_DELETE_LIMIT.
29#
30
31forcedelete test.db2
32
33do_execsql_test e_update-0.0 {
34  ATTACH 'test.db2' AS aux;
35  CREATE TABLE t1(a, b);
36  CREATE TABLE t2(a, b, c);
37  CREATE TABLE t3(a, b UNIQUE);
38  CREATE TABLE t6(x, y);
39  CREATE INDEX i1 ON t1(a);
40
41  CREATE TEMP TABLE t4(x, y);
42  CREATE TEMP TABLE t6(x, y);
43
44  CREATE TABLE aux.t1(a, b);
45  CREATE TABLE aux.t5(a, b);
46} {}
47
48proc do_update_tests {args} {
49  uplevel do_select_tests $args
50}
51
52# -- syntax diagram update-stmt
53#
54do_update_tests e_update-0 {
55  1    "UPDATE t1 SET a=10" {}
56  2    "UPDATE t1 SET a=10, b=5" {}
57  3    "UPDATE t1 SET a=10 WHERE b=5" {}
58  4    "UPDATE t1 SET b=5,a=10 WHERE 1" {}
59  5    "UPDATE main.t1 SET a=10" {}
60  6    "UPDATE main.t1 SET a=10, b=5" {}
61  7    "UPDATE main.t1 SET a=10 WHERE b=5" {}
62  9    "UPDATE OR ROLLBACK t1 SET a=10" {}
63  10   "UPDATE OR ROLLBACK t1 SET a=10, b=5" {}
64  11   "UPDATE OR ROLLBACK t1 SET a=10 WHERE b=5" {}
65  12   "UPDATE OR ROLLBACK t1 SET b=5,a=10 WHERE 1" {}
66  13   "UPDATE OR ROLLBACK main.t1 SET a=10" {}
67  14   "UPDATE OR ROLLBACK main.t1 SET a=10, b=5" {}
68  15   "UPDATE OR ROLLBACK main.t1 SET a=10 WHERE b=5" {}
69  16   "UPDATE OR ROLLBACK main.t1 SET b=5,a=10 WHERE 1" {}
70  17   "UPDATE OR ABORT t1 SET a=10" {}
71  18   "UPDATE OR ABORT t1 SET a=10, b=5" {}
72  19   "UPDATE OR ABORT t1 SET a=10 WHERE b=5" {}
73  20   "UPDATE OR ABORT t1 SET b=5,a=10 WHERE 1" {}
74  21   "UPDATE OR ABORT main.t1 SET a=10" {}
75  22   "UPDATE OR ABORT main.t1 SET a=10, b=5" {}
76  23   "UPDATE OR ABORT main.t1 SET a=10 WHERE b=5" {}
77  24   "UPDATE OR ABORT main.t1 SET b=5,a=10 WHERE 1" {}
78  25   "UPDATE OR REPLACE t1 SET a=10" {}
79  26   "UPDATE OR REPLACE t1 SET a=10, b=5" {}
80  27   "UPDATE OR REPLACE t1 SET a=10 WHERE b=5" {}
81  28   "UPDATE OR REPLACE t1 SET b=5,a=10 WHERE 1" {}
82  29   "UPDATE OR REPLACE main.t1 SET a=10" {}
83  30   "UPDATE OR REPLACE main.t1 SET a=10, b=5" {}
84  31   "UPDATE OR REPLACE main.t1 SET a=10 WHERE b=5" {}
85  32   "UPDATE OR REPLACE main.t1 SET b=5,a=10 WHERE 1" {}
86  33   "UPDATE OR FAIL t1 SET a=10" {}
87  34   "UPDATE OR FAIL t1 SET a=10, b=5" {}
88  35   "UPDATE OR FAIL t1 SET a=10 WHERE b=5" {}
89  36   "UPDATE OR FAIL t1 SET b=5,a=10 WHERE 1" {}
90  37   "UPDATE OR FAIL main.t1 SET a=10" {}
91  38   "UPDATE OR FAIL main.t1 SET a=10, b=5" {}
92  39   "UPDATE OR FAIL main.t1 SET a=10 WHERE b=5" {}
93  40   "UPDATE OR FAIL main.t1 SET b=5,a=10 WHERE 1" {}
94  41   "UPDATE OR IGNORE t1 SET a=10" {}
95  42   "UPDATE OR IGNORE t1 SET a=10, b=5" {}
96  43   "UPDATE OR IGNORE t1 SET a=10 WHERE b=5" {}
97  44   "UPDATE OR IGNORE t1 SET b=5,a=10 WHERE 1" {}
98  45   "UPDATE OR IGNORE main.t1 SET a=10" {}
99  46   "UPDATE OR IGNORE main.t1 SET a=10, b=5" {}
100  47   "UPDATE OR IGNORE main.t1 SET a=10 WHERE b=5" {}
101  48   "UPDATE OR IGNORE main.t1 SET b=5,a=10 WHERE 1" {}
102}
103
104# EVIDENCE-OF: R-38515-45264 An UPDATE statement is used to modify a
105# subset of the values stored in zero or more rows of the database table
106# identified by the qualified-table-name specified as part of the UPDATE
107# statement.
108#
109#     Test cases e_update-1.1.1.* test the "identified by the
110#     qualified-table-name" part of the statement above. Tests
111#     e_update-1.1.2.* show that the "zero or more rows" part is
112#     accurate.
113#
114do_execsql_test e_update-1.1.0 {
115  INSERT INTO main.t1 VALUES(1, 'i');
116  INSERT INTO main.t1 VALUES(2, 'ii');
117  INSERT INTO main.t1 VALUES(3, 'iii');
118
119  INSERT INTO aux.t1 VALUES(1, 'I');
120  INSERT INTO aux.t1 VALUES(2, 'II');
121  INSERT INTO aux.t1 VALUES(3, 'III');
122} {}
123do_update_tests e_update-1.1 {
124  1.1  "UPDATE t1 SET a = a+1; SELECT * FROM t1"             {2 i  3 ii  4 iii}
125  1.2  "UPDATE main.t1 SET a = a+1; SELECT * FROM main.t1"   {3 i  4 ii  5 iii}
126  1.3  "UPDATE aux.t1 SET a = a+1; SELECT * FROM aux.t1"     {2 I  3 II  4 III}
127
128  2.1  "UPDATE t1 SET a = a+1 WHERE a = 1; SELECT * FROM t1" {3 i  4 ii  5 iii}
129  2.2  "UPDATE t1 SET a = a+1 WHERE a = 4; SELECT * FROM t1" {3 i  5 ii  5 iii}
130}
131
132# EVIDENCE-OF: R-55869-30521 If the UPDATE statement does not have a
133# WHERE clause, all rows in the table are modified by the UPDATE.
134#
135do_execsql_test e_update-1.2.0 {
136  DELETE FROM main.t1;
137  INSERT INTO main.t1 VALUES(1, 'i');
138  INSERT INTO main.t1 VALUES(2, 'ii');
139  INSERT INTO main.t1 VALUES(3, 'iii');
140} {}
141do_update_tests e_update-1.2 {
142  1  "UPDATE t1 SET b = 'roman' ; SELECT * FROM t1"
143     {1 roman  2 roman  3 roman}
144
145  2  "UPDATE t1 SET a = 'greek' ; SELECT * FROM t1"
146     {greek roman  greek roman  greek roman}
147}
148
149# EVIDENCE-OF: R-58095-46013 Otherwise, the UPDATE affects only those
150# rows for which the WHERE clause boolean expression is true.
151#
152do_execsql_test e_update-1.3.0 {
153  DELETE FROM main.t1;
154  INSERT INTO main.t1 VALUES(NULL, '');
155  INSERT INTO main.t1 VALUES(1, 'i');
156  INSERT INTO main.t1 VALUES(2, 'ii');
157  INSERT INTO main.t1 VALUES(3, 'iii');
158} {}
159do_update_tests e_update-1.3 {
160  1  "UPDATE t1 SET b = 'roman' WHERE a<2 ; SELECT * FROM t1"
161     {{} {}  1 roman  2 ii  3 iii}
162
163  2  "UPDATE t1 SET b = 'egyptian' WHERE (a-3)/10.0 ; SELECT * FROM t1"
164     {{} {}  1 egyptian  2 egyptian  3 iii}
165
166  3  "UPDATE t1 SET b = 'macedonian' WHERE a; SELECT * FROM t1"
167     {{} {}  1 macedonian  2 macedonian  3 macedonian}
168
169  4  "UPDATE t1 SET b = 'lithuanian' WHERE a IS NULL; SELECT * FROM t1"
170     {{} lithuanian  1 macedonian  2 macedonian  3 macedonian}
171}
172
173# EVIDENCE-OF: R-58129-20729 It is not an error if the WHERE clause does
174# not evaluate to true for any row in the table - this just means that
175# the UPDATE statement affects zero rows.
176#
177do_execsql_test e_update-1.4.0 {
178  DELETE FROM main.t1;
179  INSERT INTO main.t1 VALUES(NULL, '');
180  INSERT INTO main.t1 VALUES(1, 'i');
181  INSERT INTO main.t1 VALUES(2, 'ii');
182  INSERT INTO main.t1 VALUES(3, 'iii');
183} {}
184do_update_tests e_update-1.4 -query {
185  SELECT * FROM t1
186} {
187  1  "UPDATE t1 SET b = 'burmese' WHERE a=5" {{} {}  1 i  2 ii  3 iii}
188
189  2  "UPDATE t1 SET b = 'burmese' WHERE length(b)<1 AND a IS NOT NULL"
190     {{} {}  1 i  2 ii  3 iii}
191
192  3  "UPDATE t1 SET b = 'burmese' WHERE 0" {{} {}  1 i  2 ii  3 iii}
193
194  4  "UPDATE t1 SET b = 'burmese' WHERE (SELECT a FROM t1 WHERE rowid=1)"
195     {{} {}  1 i  2 ii  3 iii}
196}
197
198# EVIDENCE-OF: R-40598-36595 For each affected row, the named columns
199# are set to the values found by evaluating the corresponding scalar
200# expressions.
201#
202# EVIDENCE-OF: R-40472-60438 Columns that do not appear in the list of
203# assignments are left unmodified.
204#
205do_execsql_test e_update-1.5.0 {
206  INSERT INTO t2(rowid, a, b, c) VALUES(1,  3, 1, 4);
207  INSERT INTO t2(rowid, a, b, c) VALUES(2,  1, 5, 9);
208  INSERT INTO t2(rowid, a, b, c) VALUES(3,  2, 6, 5);
209} {}
210do_update_tests e_update-1.5 -query {
211  SELECT * FROM t2
212} {
213  1   "UPDATE t2 SET c = 1+1 WHERE a=2"
214      {3 1 4   1 5 9   2 6 2}
215
216  2   "UPDATE t2 SET b = 4/2, c=CAST((0.4*5) AS INTEGER) WHERE a<3"
217      {3 1 4   1 2 2   2 2 2}
218
219  3   "UPDATE t2 SET a = 1"
220      {1 1 4   1 2 2   1 2 2}
221
222  4   "UPDATE t2 SET b = (SELECT count(*)+2 FROM t2), c = 24/3+1 WHERE rowid=2"
223      {1 1 4   1 5 9   1 2 2}
224
225  5   "UPDATE t2 SET a = 3 WHERE c = 4"
226      {3 1 4   1 5 9   1 2 2}
227
228  6   "UPDATE t2 SET a = b WHERE rowid>2"
229      {3 1 4   1 5 9   2 2 2}
230
231  6   "UPDATE t2 SET b=6, c=5 WHERE a=b AND b=c"
232      {3 1 4   1 5 9   2 6 5}
233}
234
235# EVIDENCE-OF: R-34751-18293 If a single column-name appears more than
236# once in the list of assignment expressions, all but the rightmost
237# occurrence is ignored.
238#
239do_update_tests e_update-1.6 -query {
240  SELECT * FROM t2
241} {
242  1   "UPDATE t2 SET c=5, c=6, c=7 WHERE rowid=1" {3 1 7   1 5 9   2 6 5}
243  2   "UPDATE t2 SET c=7, c=6, c=5 WHERE rowid=1" {3 1 5   1 5 9   2 6 5}
244  3   "UPDATE t2 SET c=5, b=6, c=7 WHERE rowid=1" {3 6 7   1 5 9   2 6 5}
245}
246
247# EVIDENCE-OF: R-36239-04077 The scalar expressions may refer to columns
248# of the row being updated.
249#
250# EVIDENCE-OF: R-04558-24451 In this case all scalar expressions are
251# evaluated before any assignments are made.
252#
253do_execsql_test e_update-1.7.0 {
254  DELETE FROM t2;
255  INSERT INTO t2(rowid, a, b, c) VALUES(1,  3, 1, 4);
256  INSERT INTO t2(rowid, a, b, c) VALUES(2,  1, 5, 9);
257  INSERT INTO t2(rowid, a, b, c) VALUES(3,  2, 6, 5);
258} {}
259do_update_tests e_update-1.7 -query {
260  SELECT * FROM t2
261} {
262  1   "UPDATE t2 SET a=b+c"          {5 1 4     14 5 9   11  6 5}
263  2   "UPDATE t2 SET a=b, b=a"       {1 5 4     5 14 9    6 11 5}
264  3   "UPDATE t2 SET a=c||c, c=NULL" {44 5 {}  99 14 {}  55 11 {}}
265}
266
267# EVIDENCE-OF: R-28518-13457 The optional "OR action" conflict clause
268# that follows the UPDATE keyword allows the user to nominate a specific
269# constraint conflict resolution algorithm to use during this one UPDATE
270# command.
271#
272do_execsql_test e_update-1.8.0 {
273  DELETE FROM t3;
274  INSERT INTO t3 VALUES(1, 'one');
275  INSERT INTO t3 VALUES(2, 'two');
276  INSERT INTO t3 VALUES(3, 'three');
277  INSERT INTO t3 VALUES(4, 'four');
278} {}
279foreach {tn sql error ac data } {
280  1  "UPDATE t3 SET b='one' WHERE a=3"
281     {UNIQUE constraint failed: t3.b} 1 {1 one 2 two 3 three 4 four}
282
283  2  "UPDATE OR REPLACE t3 SET b='one' WHERE a=3"
284     {} 1 {2 two 3 one 4 four}
285
286  3  "UPDATE OR FAIL t3 SET b='three'"
287     {UNIQUE constraint failed: t3.b} 1 {2 three 3 one 4 four}
288
289  4  "UPDATE OR IGNORE t3 SET b='three' WHERE a=3"
290     {} 1 {2 three 3 one 4 four}
291
292  5  "UPDATE OR ABORT t3 SET b='three' WHERE a=3"
293     {UNIQUE constraint failed: t3.b} 1 {2 three 3 one 4 four}
294
295  6  "BEGIN" {} 0 {2 three 3 one 4 four}
296
297  7  "UPDATE t3 SET b='three' WHERE a=3"
298     {UNIQUE constraint failed: t3.b} 0 {2 three 3 one 4 four}
299
300  8  "UPDATE OR ABORT t3 SET b='three' WHERE a=3"
301     {UNIQUE constraint failed: t3.b} 0 {2 three 3 one 4 four}
302
303  9  "UPDATE OR FAIL t3 SET b='two'"
304     {UNIQUE constraint failed: t3.b} 0 {2 two 3 one 4 four}
305
306  10 "UPDATE OR IGNORE t3 SET b='four' WHERE a=3"
307     {} 0 {2 two 3 one 4 four}
308
309  11 "UPDATE OR REPLACE t3 SET b='four' WHERE a=3"
310     {} 0 {2 two 3 four}
311
312  12 "UPDATE OR ROLLBACK t3 SET b='four'"
313     {UNIQUE constraint failed: t3.b} 1 {2 three 3 one 4 four}
314} {
315  do_catchsql_test e_update-1.8.$tn.1 $sql [list [expr {$error!=""}] $error]
316  do_execsql_test  e_update-1.8.$tn.2 {SELECT * FROM t3} [list {*}$data]
317  do_test          e_update-1.8.$tn.3 {sqlite3_get_autocommit db} $ac
318}
319
320
321
322# EVIDENCE-OF: R-12123-54095 The table-name specified as part of an
323# UPDATE statement within a trigger body must be unqualified.
324#
325# EVIDENCE-OF: R-43190-62442 In other words, the schema-name. prefix on
326# the table name of the UPDATE is not allowed within triggers.
327#
328do_update_tests e_update-2.1 -error {
329  qualified table names are not allowed on INSERT, UPDATE, and DELETE statements within triggers
330} {
331  1 {
332      CREATE TRIGGER tr1 AFTER INSERT ON t1 BEGIN
333        UPDATE main.t2 SET a=1, b=2, c=3;
334      END;
335  } {}
336
337  2 {
338      CREATE TRIGGER tr1 BEFORE UPDATE ON t2 BEGIN
339        UPDATE aux.t1 SET a=1, b=2;
340      END;
341  } {}
342
343  3 {
344      CREATE TRIGGER tr1 AFTER DELETE ON t4 BEGIN
345        UPDATE main.t1 SET a=1, b=2;
346      END;
347  } {}
348}
349
350# EVIDENCE-OF: R-06085-13761 Unless the table to which the trigger is
351# attached is in the TEMP database, the table being updated by the
352# trigger program must reside in the same database as it.
353#
354do_update_tests e_update-2.2 -error {
355  no such table: %s
356} {
357  1 {
358      CREATE TRIGGER tr1 AFTER INSERT ON t1 BEGIN
359        UPDATE t4 SET x=x+1;
360      END;
361      INSERT INTO t1 VALUES(1, 2);
362  } "main.t4"
363
364  2 {
365      CREATE TRIGGER aux.tr1 AFTER INSERT ON t5 BEGIN
366        UPDATE t4 SET x=x+1;
367      END;
368      INSERT INTO t5 VALUES(1, 2);
369  } "aux.t4"
370}
371do_execsql_test e_update-2.2.X {
372  DROP TRIGGER tr1;
373  DROP TRIGGER aux.tr1;
374} {}
375
376# EVIDENCE-OF: R-29512-54644 If the table to which the trigger is
377# attached is in the TEMP database, then the unqualified name of the
378# table being updated is resolved in the same way as it is for a
379# top-level statement (by searching first the TEMP database, then the
380# main database, then any other databases in the order they were
381# attached).
382#
383do_execsql_test e_update-2.3.0 {
384  SELECT 'main', tbl_name FROM main.sqlite_master WHERE type = 'table';
385  SELECT 'temp', tbl_name FROM sqlite_temp_master WHERE type = 'table';
386  SELECT 'aux', tbl_name FROM aux.sqlite_master WHERE type = 'table';
387} [list {*}{
388    main t1
389    main t2
390    main t3
391    main t6
392    temp t4
393    temp t6
394    aux  t1
395    aux  t5
396}]
397do_execsql_test e_update-2.3.1 {
398  DELETE FROM main.t6;
399  DELETE FROM temp.t6;
400  INSERT INTO main.t6 VALUES(1, 2);
401  INSERT INTO temp.t6 VALUES(1, 2);
402
403  CREATE TRIGGER temp.tr1 AFTER INSERT ON t4 BEGIN
404    UPDATE t6 SET x=x+1;
405  END;
406
407  INSERT INTO t4 VALUES(1, 2);
408  SELECT * FROM main.t6;
409  SELECT * FROM temp.t6;
410} {1 2 2 2}
411do_execsql_test e_update-2.3.2 {
412  DELETE FROM main.t1;
413  DELETE FROM aux.t1;
414  INSERT INTO main.t1 VALUES(1, 2);
415  INSERT INTO aux.t1 VALUES(1, 2);
416
417  CREATE TRIGGER temp.tr2 AFTER DELETE ON t4 BEGIN
418    UPDATE t1 SET a=a+1;
419  END;
420
421  DELETE FROM t4;
422  SELECT * FROM main.t1;
423  SELECT * FROM aux.t1;
424} {2 2 1 2}
425do_execsql_test e_update-2.3.3 {
426  DELETE FROM aux.t5;
427  INSERT INTO aux.t5 VALUES(1, 2);
428
429  INSERT INTO t4 VALUES('x', 'y');
430  CREATE TRIGGER temp.tr3 AFTER UPDATE ON t4 BEGIN
431    UPDATE t5 SET a=a+1;
432  END;
433
434  UPDATE t4 SET x=10;
435  SELECT * FROM aux.t5;
436} {2 2}
437
438# EVIDENCE-OF: R-19619-42762 The INDEXED BY and NOT INDEXED clauses are
439# not allowed on UPDATE statements within triggers.
440#
441do_update_tests e_update-2.4 -error {
442  the %s %s clause is not allowed on UPDATE or DELETE statements within triggers
443} {
444  1 {
445      CREATE TRIGGER tr1 AFTER INSERT ON t2 BEGIN
446        UPDATE t1 INDEXED BY i1 SET a=a+1;
447      END;
448  } {INDEXED BY}
449
450  2 {
451      CREATE TRIGGER tr1 AFTER INSERT ON t2 BEGIN
452        UPDATE t1 NOT INDEXED SET a=a+1;
453      END;
454  } {NOT INDEXED}
455}
456
457ifcapable update_delete_limit {
458
459# EVIDENCE-OF: R-57359-59558 The LIMIT and ORDER BY clauses for UPDATE
460# are unsupported within triggers, regardless of the compilation options
461# used to build SQLite.
462#
463do_update_tests e_update-2.5 -error {
464  near "%s": syntax error
465} {
466  1 {
467      CREATE TRIGGER tr1 AFTER INSERT ON t2 BEGIN
468        UPDATE t1 SET a=a+1 LIMIT 10;
469      END;
470  } {LIMIT}
471
472  2 {
473      CREATE TRIGGER tr1 AFTER INSERT ON t2 BEGIN
474        UPDATE t1 SET a=a+1 ORDER BY a LIMIT 10;
475      END;
476  } {ORDER}
477
478  3 {
479      CREATE TRIGGER tr1 AFTER INSERT ON t2 BEGIN
480        UPDATE t1 SET a=a+1 ORDER BY a LIMIT 10 OFFSET 2;
481      END;
482  } {ORDER}
483
484  4 {
485      CREATE TRIGGER tr1 AFTER INSERT ON t2 BEGIN
486        UPDATE t1 SET a=a+1 LIMIT 10 OFFSET 2;
487      END;
488  } {LIMIT}
489}
490
491# EVIDENCE-OF: R-59581-44104 If SQLite is built with the
492# SQLITE_ENABLE_UPDATE_DELETE_LIMIT compile-time option then the syntax
493# of the UPDATE statement is extended with optional ORDER BY and LIMIT
494# clauses
495#
496# -- syntax diagram update-stmt-limited
497#
498do_update_tests e_update-3.0 {
499  1   "UPDATE t1 SET a=b LIMIT 5"                                    {}
500  2   "UPDATE t1 SET a=b LIMIT 5-1 OFFSET 2+2"                       {}
501  3   "UPDATE t1 SET a=b LIMIT 2+2, 16/4"                            {}
502  4   "UPDATE t1 SET a=b ORDER BY a LIMIT 5"                         {}
503  5   "UPDATE t1 SET a=b ORDER BY a LIMIT 5-1 OFFSET 2+2"            {}
504  6   "UPDATE t1 SET a=b ORDER BY a LIMIT 2+2, 16/4"                 {}
505  7   "UPDATE t1 SET a=b WHERE a>2 LIMIT 5"                          {}
506  8   "UPDATE t1 SET a=b WHERE a>2 LIMIT 5-1 OFFSET 2+2"             {}
507  9   "UPDATE t1 SET a=b WHERE a>2 LIMIT 2+2, 16/4"                  {}
508  10  "UPDATE t1 SET a=b WHERE a>2 ORDER BY a LIMIT 5"               {}
509  11  "UPDATE t1 SET a=b WHERE a>2 ORDER BY a LIMIT 5-1 OFFSET 2+2"  {}
510  12  "UPDATE t1 SET a=b WHERE a>2 ORDER BY a LIMIT 2+2, 16/4"       {}
511}
512
513do_execsql_test e_update-3.1.0 {
514  CREATE TABLE t7(q, r, s);
515  INSERT INTO t7 VALUES(1, 'one',   'X');
516  INSERT INTO t7 VALUES(2, 'two',   'X');
517  INSERT INTO t7 VALUES(3, 'three', 'X');
518  INSERT INTO t7 VALUES(4, 'four',  'X');
519  INSERT INTO t7 VALUES(5, 'five',  'X');
520  INSERT INTO t7 VALUES(6, 'six',   'X');
521  INSERT INTO t7 VALUES(7, 'seven', 'X');
522  INSERT INTO t7 VALUES(8, 'eight', 'X');
523  INSERT INTO t7 VALUES(9, 'nine',  'X');
524  INSERT INTO t7 VALUES(10, 'ten',  'X');
525} {}
526
527# EVIDENCE-OF: R-58862-44169 If an UPDATE statement has a LIMIT clause,
528# the maximum number of rows that will be updated is found by evaluating
529# the accompanying expression and casting it to an integer value.
530#
531do_update_tests e_update-3.1 -query { SELECT s FROM t7 } {
532  1   "UPDATE t7 SET s = q LIMIT 5"            {1 2 3 4 5 X X X X X}
533  2   "UPDATE t7 SET s = r WHERE q>2 LIMIT 4"  {1 2 three four five six X X X X}
534  3   "UPDATE t7 SET s = q LIMIT 0"            {1 2 three four five six X X X X}
535}
536
537# EVIDENCE-OF: R-63582-45120 A negative value is interpreted as "no limit".
538#
539do_update_tests e_update-3.2 -query { SELECT s FROM t7 } {
540  1   "UPDATE t7 SET s = q LIMIT -1"              {1 2 3 4 5 6 7 8 9 10}
541  2   "UPDATE t7 SET s = r WHERE q>4 LIMIT -1"
542      {1 2 3 4 five six seven eight nine ten}
543  3   "UPDATE t7 SET s = 'X' LIMIT -1"            {X X X X X X X X X X}
544}
545
546# EVIDENCE-OF: R-18628-11938 If the LIMIT expression evaluates to
547# non-negative value N and the UPDATE statement has an ORDER BY clause,
548# then all rows that would be updated in the absence of the LIMIT clause
549# are sorted according to the ORDER BY and the first N updated.
550#
551do_update_tests e_update-3.3 -query { SELECT s FROM t7 } {
552  1   "UPDATE t7 SET s = q ORDER BY r LIMIT 3"      {X X X 4 5 X X 8 X X}
553  2   "UPDATE t7 SET s = r ORDER BY r DESC LIMIT 2" {X two three 4 5 X X 8 X X}
554  3   "UPDATE t7 SET s = q ORDER BY q DESC LIMIT 5" {X two three 4 5 6 7 8 9 10}
555
556  X   "UPDATE t7 SET s = 'X'"                       {X X X X X X X X X X}
557}
558
559# EVIDENCE-OF: R-30955-38324 If the UPDATE statement also has an OFFSET
560# clause, then it is similarly evaluated and cast to an integer value.
561# If the OFFSET expression evaluates to a non-negative value M, then the
562# first M rows are skipped and the following N rows updated instead.
563#
564do_update_tests e_update-3.3 -query { SELECT s FROM t7 } {
565  1   "UPDATE t7 SET s = q ORDER BY q LIMIT 3 OFFSET 2"  {X X 3 4 5 X X X X X}
566  2   "UPDATE t7 SET s = q ORDER BY q DESC LIMIT 2, 3 "  {X X 3 4 5 6 7 8 X X}
567
568  X   "UPDATE t7 SET s = 'X'"                       {X X X X X X X X X X}
569}
570
571# EVIDENCE-OF: R-19486-35828 If the UPDATE statement has no ORDER BY
572# clause, then all rows that would be updated in the absence of the
573# LIMIT clause are assembled in an arbitrary order before applying the
574# LIMIT and OFFSET clauses to determine which are actually updated.
575#
576#     In practice, "arbitrary order" is rowid order. This is also tested
577#     by e_update-3.2.* above.
578#
579do_update_tests e_update-3.4 -query { SELECT s FROM t7 } {
580  1   "UPDATE t7 SET s = q LIMIT 4, 2"        {X X X X 5 6 X X X X}
581  2   "UPDATE t7 SET s = q LIMIT 2 OFFSET 7"  {X X X X 5 6 X 8 9 X}
582}
583
584# EVIDENCE-OF: R-10927-26133 The ORDER BY clause on an UPDATE statement
585# is used only to determine which rows fall within the LIMIT. The order
586# in which rows are modified is arbitrary and is not influenced by the
587# ORDER BY clause.
588#
589do_execsql_test e_update-3.5.0 {
590  CREATE TABLE t8(x);
591  CREATE TRIGGER tr7 BEFORE UPDATE ON t7 BEGIN
592    INSERT INTO t8 VALUES(old.q);
593  END;
594} {}
595do_update_tests e_update-3.5 -query { SELECT x FROM t8 ; DELETE FROM t8 } {
596  1   "UPDATE t7 SET s = q ORDER BY r LIMIT -1"        {1 2 3 4 5 6 7 8 9 10}
597  2   "UPDATE t7 SET s = q ORDER BY r ASC LIMIT -1"    {1 2 3 4 5 6 7 8 9 10}
598  3   "UPDATE t7 SET s = q ORDER BY r DESC LIMIT -1"   {1 2 3 4 5 6 7 8 9 10}
599  4   "UPDATE t7 SET s = q ORDER BY q DESC LIMIT 5"    {6 7 8 9 10}
600}
601
602
603} ;# ifcapable update_delete_limit
604
605finish_test
606