← Back to branch summary

~drizzle-trunk/drizzle/development

« back to all changes in this revision

Viewing changes to tests/t/microsecond.test

  • Committer: Prafulla Tekawade
  • Date: 2010-07-18 03:36:32 UTC
  • mto: (1662.1.4 rollup)
  • mto: This revision was merged to the branch mainline in revision 1664.
  • Revision ID: prafulla_t@users.sourceforge.net-20100718033632-p7q6qtgliqbhe38p
Fix for Bug 592444

There were two problems:
o. In greedy_search optimizer method, best_extension_by_limited search
   maintains join embedding(nestedness) of tables added so far, so that 
   correct(valid)  join order is selected
   These are requirements from nested outer join executioner.
   The problem was, embedding_map was not correctly updated when a table 
   is added to optimal plan outside best_extension_by_limited search, 
   by greedy_search method. We need to update join->cur_embedding_map
   correctly here so that execution plan for other tables get
   generated.
   Invoked checked_interleaving_with_nj from greedy_search on the
   best_table selected. Fixed its prototype to take only one JoinTab
   This is same as mysql 5.1 source tree.
o. The other problem was, join->cur_embedding_map was not restored correctly
   when a table is added to the optimal plan to reflect the current embedding 
   map. 
   Taken good documented method restore_prev_nj_state which restores 
   cur_embedding_map from mysql 5.1 source tree and modified it for drizzled 
   code.

Show diffs side-by-side

added added

removed removed

Lines of Context:
tests/t/microsecond.test
16
16
# Test improper argument list 
17
17
#
18
18
# 1 arg is required.
19
 
--error ER_PARSE_ERROR 
 
19
--error 1064 
20
20
# Wrong parameter count...but unfortunately produces 1064 Syntax Error due to limitations of 
21
21
# the SQL parser, which considers MICROSECOND a keyword before being a function symbol
22
22
SELECT MICROSECOND();
23
 
--error ER_PARSE_ERROR
 
23
--error 1064
24
24
# Wrong parameter count...but unfortunately produces 1064 Syntax Error due to limitations of 
25
25
# the SQL parser, which considers MICROSECOND a keyword before being a function symbol
26
26
SELECT MICROSECOND(1, 0);
30
30
# produce an error, not a NULL or anything
31
31
# else...
32
32
#
33
 
--error ER_INVALID_DATETIME_VALUE
 
33
--error 1686
34
34
SELECT MICROSECOND("xxx");
35
35
 
36
36
# 
39
39
# The following are all bad dates, with no possibility of interpreting
40
40
# the values as TIME-only components.
41
41
#
42
 
--error ER_INVALID_DATETIME_VALUE
 
42
--error 1686
43
43
SELECT MICROSECOND("0000-00-00"); # No 0000-00-00 dates!...
44
 
--error ER_INVALID_DATETIME_VALUE
 
44
--error 1686
45
45
SELECT MICROSECOND("0000-01-01"); # No zero year parts
46
 
--error ER_INVALID_DATETIME_VALUE
 
46
--error 1686
47
47
SELECT MICROSECOND("0001-00-01"); # No zero month parts
48
 
--error ER_INVALID_DATETIME_VALUE
 
48
--error 1686
49
49
SELECT MICROSECOND("0001-01-00"); # No zero day parts
50
 
--error ER_INVALID_DATETIME_VALUE
 
50
--error 1686
51
51
SELECT MICROSECOND("2000-02-30"); # No Feb 30th!
52
 
--error ER_INVALID_DATETIME_VALUE
 
52
--error 1686
53
53
SELECT MICROSECOND("1900-02-29"); # Not a leap MICROSECOND since not divisible evenly by 400...
54
 
--error ER_INVALID_DATETIME_VALUE
 
54
--error 1686
55
55
SELECT MICROSECOND('1976-15-15'); # No 15th month!
56
 
--error ER_INVALID_DATETIME_VALUE
 
56
--error 1686
57
57
SELECT MICROSECOND('23:59:70'); # No 70th second!
58
 
--error ER_INVALID_DATETIME_VALUE
 
58
--error 1686
59
59
SELECT MICROSECOND('23:70:59'); # No 70th minute!
60
 
--error ER_INVALID_DATETIME_VALUE
 
60
--error 1686
61
61
SELECT MICROSECOND('26:00:00'); # No 26th hour!
62
 
--error ER_INVALID_DATETIME_VALUE
 
62
--error 1686
63
63
SELECT MICROSECOND('26:00:00.9999999'); # Microseconds are 6 places, not 7
64
64
 
65
65
# A good date, which cannot be interpreted as a TIME component.  Should return 0.