1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
|
#!/usr/bin/env tarantool
test = require("sqltester")
test:plan(22)
--!./tcltestrunner.lua
-- 2010 August 27
--
-- The author disclaims copyright to this source code. In place of
-- a legal notice, here is a blessing:
--
-- May you do good and not evil.
-- May you find forgiveness for yourself and forgive others.
-- May you share freely, never taking more than you give.
--
-------------------------------------------------------------------------
--
-- Testing of function factoring and the sql_DETERMINISTIC flag.
--
-- Verify that constant string expressions that get factored into initializing
-- code are not reused between function parameters and other values in the
-- VDBE program, as the function might have changed the encoding.
--
test:do_execsql_test(
"func5-1.1",
[[
CREATE TABLE t1(x INT PRIMARY KEY,a TEXT,b TEXT,c INT );
INSERT INTO t1 VALUES(1,'ab','cd',1);
INSERT INTO t1 VALUES(2,'gh','ef',5);
INSERT INTO t1 VALUES(3,'pqr','fuzzy',99);
INSERT INTO t1 VALUES(4,'abcdefg','xy',22);
INSERT INTO t1 VALUES(5,'shoe','mayer',2953);
SELECT x FROM t1 WHERE c=position(b, 'abcdefg') OR a='abcdefg' ORDER BY +x;
]], {
-- <func5-1.1>
2, 4
-- </func5-1.1>
})
test:do_execsql_test(
"func5-1.2",
[[
SELECT x FROM t1 WHERE a='abcdefg' OR c=position(b, 'abcdefg') ORDER BY +x;
]], {
-- <func5-1.1>
2, 4
-- </func5-1.1>
})
-- Verify that sql_DETERMINISTIC functions get factored out of the
-- evaluation loop whereas non-deterministic functions do not. counter1()
-- is marked as non-deterministic and so is not factored out of the loop,
-- and it really is non-deterministic, returning a different result each
-- time. But counter2() is marked as deterministic, so it does get factored
-- out of the loop. counter2() has the same implementation as counter1(),
-- returning a different result on each invocation, but because it is
-- only invoked once outside of the loop, it appears to return the same
-- result multiple times.
--
test:do_execsql_test(
"func5-2.1",
[[
CREATE TABLE t2(x INT PRIMARY KEY,y INT );
INSERT INTO t2 VALUES(1,2),(3,4),(5,6),(7,8);
SELECT x, y FROM t2 WHERE x+5=5+x ORDER BY +x;
]], {
-- <func5-2.1>
1, 2, 3, 4, 5, 6, 7, 8
-- </func5-2.1>
})
global_counter = 0
box.schema.func.create('COUNTER1', {language = 'Lua', is_deterministic = false,
param_list = {'any'}, returns = 'integer',
exports = {'SQL', 'LUA'},
body = [[
function(str)
global_counter = global_counter + 1
return global_counter
end
]]})
box.schema.func.create('COUNTER2', {language = 'Lua', is_deterministic = true,
param_list = {'any'}, returns = 'integer',
exports = {'SQL', 'LUA'},
body = [[
function(str)
global_counter = global_counter + 1
return global_counter
end
]]})
test:do_execsql_test(
"func5-2.2",
[[
SELECT x, y FROM t2 WHERE x+counter1('hello')=counter1('hello')+x ORDER BY +x;
]], {
-- <func5-2.2>
-- </func5-2.2>
})
test:do_execsql_test(
"func5-2.3",
[[
SELECT x, y FROM t2 WHERE x+counter2('hello')=counter2('hello')+x ORDER BY +x;
]], {
-- <func5-2.2>
1, 2, 3, 4, 5, 6, 7, 8
-- </func5-2.2>
})
-- The following tests ensures that GREATEST() and LEAST()
-- functions raise error if argument's collations are incompatible.
test:do_catchsql_test(
"func-5-3.1",
[[
SELECT GREATEST('a' COLLATE "unicode", 'A' COLLATE "unicode_ci");
]],
{
-- <func5-3.1>
1, "Illegal mix of collations"
-- </func5-3.1>
}
)
test:do_catchsql_test(
"func-5-3.2",
[[
CREATE TABLE test1 (s1 VARCHAR(5) PRIMARY KEY COLLATE "unicode");
CREATE TABLE test2 (s2 VARCHAR(5) PRIMARY KEY COLLATE "unicode_ci");
INSERT INTO test1 VALUES ('a');
INSERT INTO test2 VALUES ('a');
SELECT GREATEST(s1, s2) FROM test1 JOIN test2;
]],
{
-- <func5-3.2>
1, "Illegal mix of collations"
-- </func5-3.2>
}
)
test:do_catchsql_test(
"func-5-3.3",
[[
SELECT GREATEST ('abc', 'asd' COLLATE "binary", 'abc' COLLATE "unicode")
]],
{
-- <func5-3.3>
1, "Illegal mix of collations"
-- </func5-3.3>
}
)
test:do_execsql_test(
"func-5-3.4",
[[
SELECT GREATEST (s1, 'asd' COLLATE "binary", s2) FROM test1 JOIN test2;
]], {
-- <func5-3.4>
"asd"
-- </func5-3.4>
}
)
test:do_catchsql_test(
"func-5.3.5",
[[
CREATE TABLE test3 (s3 VARCHAR(5) PRIMARY KEY COLLATE "unicode");
CREATE TABLE test4 (s4 VARCHAR(5) PRIMARY KEY COLLATE "unicode");
CREATE TABLE test5 (s5 VARCHAR(5) PRIMARY KEY COLLATE "binary");
INSERT INTO test3 VALUES ('a');
INSERT INTO test4 VALUES ('a');
INSERT INTO test5 VALUES ('a');
SELECT GREATEST(s3, s4, s5) FROM test3 JOIN test4 JOIN test5;
]],
{
-- <func5-3.5>
1, "Illegal mix of collations"
-- </func5-3.5>
}
)
test:do_catchsql_test(
"func-5-3.6",
[[
SELECT LEAST('a' COLLATE "unicode", 'A' COLLATE "unicode_ci");
]],
{
-- <func5-3.6>
1, "Illegal mix of collations"
-- </func5-3.6>
}
)
test:do_catchsql_test(
"func-5-3.7",
[[
SELECT LEAST(s1, s2) FROM test1 JOIN test2;
]],
{
-- <func5-3.7>
1, "Illegal mix of collations"
-- </func5-3.7>
}
)
test:do_catchsql_test(
"func-5-3.8",
[[
SELECT LEAST('abc', 'asd' COLLATE "binary", 'abc' COLLATE "unicode")
]],
{
-- <func5-3.8>
1, "Illegal mix of collations"
-- </func5-3.8>
}
)
test:do_execsql_test(
"func-5-3.9",
[[
SELECT LEAST(s1, 'asd' COLLATE "binary", s2) FROM test1 JOIN test2;
]], {
-- <func5-3.9>
"a"
-- </func5-3.9>
}
)
test:do_catchsql_test(
"func-5.3.10",
[[
SELECT LEAST(s3, s4, s5) FROM test3 JOIN test4 JOIN test5;
]],
{
-- <func5-3.10>
1, "Illegal mix of collations"
-- <func5-3.10>
}
)
-- Order of arguments of LEAST/GREATEST functions doesn't affect
-- the result: boolean is always less than numbers, which
-- are less than strings.
--
test:do_execsql_test(
"func-5-4.1",
[[
SELECT GREATEST (false, 'STR', 1, 0.5);
]], { "STR" } )
test:do_execsql_test(
"func-5-4.2",
[[
SELECT GREATEST ('STR', 1, 0.5, false);
]], { "STR" } )
test:do_execsql_test(
"func-5-4.3",
[[
SELECT LEAST('STR', 1, 0.5, false);
]], { false } )
test:do_execsql_test(
"func-5-4.4",
[[
SELECT LEAST(false, 'STR', 1, 0.5);
]], { false } )
-- gh-4453: GREATEST()/LEAST() require at least two arguments
-- be passed to these functions.
--
test:do_catchsql_test(
"func-5-5.1",
[[
SELECT LEAST(false);
]], { 1, "Wrong number of arguments is passed to LEAST(): expected at least two, got 1" } )
test:do_catchsql_test(
"func-5-5.2",
[[
SELECT GREATEST('abc');
]], { 1, "Wrong number of arguments is passed to GREATEST(): expected at least two, got 1" } )
test:do_catchsql_test(
"func-5-5.3",
[[
SELECT LEAST();
]], { 1, "Wrong number of arguments is passed to LEAST(): expected at least two, got 0" } )
box.func.COUNTER1:drop()
box.func.COUNTER2:drop()
test:finish_test()
|
