← Back to branch summary

~drizzle-trunk/drizzle/development

« back to all changes in this revision

Viewing changes to tests/t/year.test

  • Committer: Prafulla Tekawade
  • Date: 2010-08-06 11:21:12 UTC
  • mto: (1711.1.21 build) (1725.1.1 build)
  • mto: This revision was merged to the branch mainline in revision 1714.
  • Revision ID: prafulla_t@users.sourceforge.net-20100806112112-7w5u0s3nx9u67nzt
Fix for Bug 586051

1. test_if_ref method which checks whether predicate is already evaluated
   due to ref/eq_ref access or not was incorrectly removing a predicate 
   that was not implicitly evaluated due to ref access (due to presence of filesort ?)
   It was field=NULL predicate.
   Such predicate should be kept and execution engine will filter out rows
   correctly. Removal of such predicate led to returning of rows which had
   NULL for join/predicate columns.
2. field COMP_OP NULL will always false for all fields except when COMP_OP
   is NULL-safe equality operator. Modified range optimizer to return zero
   row count in such cases.
   Query now does not even run. It returns zero result. As such Fix(1) is not
   required but we might hit that case in some other query (I have not tried it
   yet)
3. Fixed Field::val_str to print "NULL" for literal NULL instead of "0". It
   added lot of confusion while debugging.

Show diffs side-by-side

added added

removed removed

Lines of Context:
tests/t/year.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 YEAR a keyword before being a function symbol
22
22
SELECT YEAR();
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 YEAR a keyword before being a function symbol
26
26
SELECT YEAR(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 YEAR("xxx");
35
35
 
36
36
# Indy, bad dates!
37
 
--error ER_INVALID_DATETIME_VALUE
 
37
--error 1686
38
38
SELECT YEAR("0000-00-00"); # No 0000-00-00 dates!...
39
 
--error ER_INVALID_DATETIME_VALUE
 
39
--error 1686
40
40
SELECT YEAR("0000-01-01"); # No zero year parts
41
 
--error ER_INVALID_DATETIME_VALUE
 
41
--error 1686
42
42
SELECT YEAR("0001-00-01"); # No zero month parts
43
 
--error ER_INVALID_DATETIME_VALUE
 
43
--error 1686
44
44
SELECT YEAR("0001-01-00"); # No zero day parts
45
 
--error ER_INVALID_DATETIME_VALUE
 
45
--error 1686
46
46
SELECT YEAR("2000-02-30"); # No Feb 30th!
47
 
--error ER_INVALID_DATETIME_VALUE
 
47
--error 1686
48
48
SELECT YEAR("1900-02-29"); # Not a leap YEAR since not divisible evenly by 400...
49
 
--error ER_INVALID_DATETIME_VALUE
 
49
--error 1686
50
50
SELECT YEAR('1976-15-15'); # No 15th month!
51
51
 
52
52
# A good date, which should output 2009