Updated MySQL time handling code to react correctly on UTC leap second additions.
MySQL functions that return the OS current time, like e.g. CURDATE(), NOW() etc
will return :59:59 instead of :59:60 or 59:61.
As a result the reader will receive :59:59 for 2 or 3 consecutive seconds 
during the leap second.
This fix will not affect the values returned by UNIX_TIMESTAMP() for leap seconds.
But note that when converting the value returned by UNIX_TIMESTAMP() to broken 
down time the correction of leap seconds will still be applied.
Note that this fix will make a difference *only* if the OS is specially configured
to return leap seconds from the OS time calls or when using a MySQL time zone 
defintion that has leap seconds.
Even after this change date/time literals (or other broken down time 
representations) with leap seconds (ending on :59:60 or 59:61) will still be 
considered illegal and discarded by the server with an error or 
a warning depending on the sql mode.
Added a test case to demonstrate the effect of the fix.

mysql-test/r/timezone3.result:
  Bug #39920: test case
mysql-test/std_data/Moscow_leap:
  Bug #39920: updated the Moscow time zone to Dr. Olson's tzdata 2008i 
  to accomodate for the 2008 leap second
mysql-test/t/timezone3.test:
  Bug #39920: test case
sql/tztime.cc:
  Bug #39920: adjust leap seconds (:60 or :61) to :59
sql/tztime.h:
  Bug #39920: adjust leap seconds (:60 or :61) to :59

by using and taking out a full path.

mysql-test/r/ctype_filesystem.result:
  Bug #37399: use MYSQL_TEST_DIR rooted test
mysql-test/t/ctype_filesystem-master.opt:
  Bug #37399: use MYSQL_TEST_DIR rooted test
mysql-test/t/ctype_filesystem.test:
  Bug #37399: use MYSQL_TEST_DIR rooted test

TABLE_LIST doesn't free Strings in its string lists
(TABLE_LIST::use_index and TABLE_liST::ignore_index), so
calling c_ptr_safe() on that Strings leads to memleaks.
OTOH "safe" c_ptr_safe() is not necessary there and we can
replace it with c_ptr().

Diff to actual 5.0-bugteam is revno: 2725 only

            an error

Even after the fix for bug 28701 visible behaviors of
SELECT FROM a view and SELECT FROM a regular table are
little bit different:

1. "SELECT FROM regular table USE/FORCE/IGNORE(non
   existent index)" fails with a "ERROR 1176 (HY000):
   Key '...' doesn't exist in table '...'"

2. "SELECT FROM view USING/FORCE/IGNORE(any index)" fails
   with a "ERROR 1221 (HY000): Incorrect usage of
   USE/IGNORE INDEX and VIEW".  OTOH "SHOW INDEX FROM
   view" always returns empty result set, so from the point
   of same behaviour view we trying to use/ignore non
   existent index.

To harmonize the behaviour of USE/FORCE/IGNORE(index)
clauses in SELECT from a view and from a regular table the
"ERROR 1221 (HY000): Incorrect usage of USE/IGNORE INDEX
and VIEW" message has been replaced with the "ERROR 1176
(HY000): Key '...' doesn't exist in table '...'" message
like for tables and non existent keys.


mysql-test/r/view.result:
  Added test case for bug #33461.
  Updated test case for bug 28701.
mysql-test/t/view.test:
  Added test case for bug #33461.
  Updated test case for bug 28701.
sql/sql_view.cc:
  Bug #33461: SELECT ... FROM <view> USE INDEX (...) throws
              an error
  
  To harmonize the behaviour of USE/FORCE/IGNORE(index)
  clauses in SELECT from a view and from a regular table the
  "ERROR 1221 (HY000): Incorrect usage of USE/IGNORE INDEX
  and VIEW" message has been replaced with the "ERROR 1176
  (HY000): Key '...' doesn't exist in table '...'" message
  like for tables and non existent keys.

      
The SHOW VARIABLES LIKE .../SELECT @@/SELECT ... FROM INFORMATION_SCHEMA.VARIABLES
were assuming that all the system variables are in system charset (UTF-8).
However the variables that are settable through command line will have a different
character set (character_set_filesystem).
Fixed the server to remember the correct character set of basedir, datadir, tmpdir,
ssl, plugin_dir, slave_load_tmpdir, innodb variables; init_connect and init_slave 
variables and use it when processing data.

mysql-test/r/ctype_filesystem.result:
  Bug #37339: test case (should be in utf-8)
mysql-test/t/ctype_filesystem-master.opt:
  Bug #37339: test case (should be in ISO-8859-1)
mysql-test/t/ctype_filesystem.test:
  Bug #37339: test case
sql/mysqld.cc:
  Bug #37339: remember the correct character set for init_slave and init_connect
sql/set_var.cc:
  Bug #37339: 
    - remember the character set of the relevant variables
    - implement storing and using the correct 
      character set
sql/set_var.h:
  Bug #37339: implement storing and using the correct 
  character set
sql/sql_show.cc:
  Bug #37339: implement storing and using the correct 
  character set

mysql-test/r/perror-win.result:
  pushbuild failure fix
mysql-test/t/perror-win.test:
  pushbuild failure fix
sql/item_func.cc:
  pushbuild failure fix

The bug is repeatable with latest(1.0.1) InnoDB plugin on Linux, Win,
If MySQL is compiled with valgrind there are errors about
using of uninitialized variable(orig_table).
The fix is to set field->orig_table correct value.


mysql-test/r/innodb_mysql.result:
  test result
mysql-test/t/innodb_mysql.test:
  test case
sql/sql_base.cc:
  set field->orig_table to 'table' value because it may be bogus and
  it leads to crash on Field_string::type() function.

enable uncacheable flag if we update a view with check option
and check option has a subselect, otherwise, the check option
can be evaluated after the subselect was freed as independent
(See full_local in JOIN::join_free())


mysql-test/r/subselect.result:
  test result
mysql-test/t/subselect.test:
  test case
sql/mysql_priv.h:
  added UNCACHEABLE_CHECKOPTION flag
sql/sql_update.cc:
  enable uncacheable flag if we update a view with check option
  and check option has a subselect, otherwise, the check option
  can be evaluated after the subselect was freed as independent
  (See full_local in JOIN::join_free())

set DATE|DATETIME value to 0 if ALLOW_INVALID_DATES sql_mode is not enabled.


sql/field.cc:
  set DATE|DATETIME value to 0 if ALLOW_INVALID_DATES sql_mode is not enabled.
tests/mysql_client_test.c:
  test case

extended perror to enable printing of Win32 system errors


extra/perror.c:
  extended perror to enable printing of Win32 system errors
mysql-test/r/perror-win.result:
  test result
mysql-test/t/perror-win.test:
  test case

We pretended that TIMEDIFF() would always return positive results;
this gave strange results in comparisons of the TIMEDIFF(low,hi)<TIME(0)
type that rendered a negative result, but still gave false in comparison.
We also inadvertantly dropped the sign when converting times to
decimal.

CAST(time AS DECIMAL) handles signs of the times correctly.
TIMEDIFF() marked up as signed. Time/date comparison code switched to
signed for clarity.

mysql-test/r/func_sapdb.result:
  show that time-related comparisons work with negative
  time values now.
  show that converting time to DECIMAL no longer drops sign.
mysql-test/t/func_sapdb.test:
  show that time-related comparisons work with negative
  time values now.
  show that converting time to DECIMAL no longer drops sign.
sql/item_cmpfunc.cc:
  signed returns
sql/item_cmpfunc.h:
  signed now (time/date < > =)
sql/item_func.cc:
  signed now
sql/item_timefunc.h:
  Functions such as TIMEDIFF() return signed results!
  The file-comments pretended we were doing that all along, anyway...
sql/my_decimal.cc:
  heed sign when converting time to my_decimal;
  times may actually be negative!
  Needed for SELECT CAST(time('-73:42:12') AS DECIMAL);
sql/mysql_priv.h:
  using signed for dates and times now

Problem: in 5.0 'check table for upgrade' doesn't detect
incompatible collation changes made in 5.0.48.

Fix: backport #39585 fix to 5.0


sql/handler.cc:
  Fix for bug#40984: backport fix from 39585 into 5.0
    - backport of #39585 fix
sql/handler.h:
  Fix for bug#40984: backport fix from 39585 into 5.0
    - backport of #39585 fix

Altering how MTR checks global variable status to exclude timestamp
Changed SQL statements to update style.

ONLY_FULL_GROUP_BY

The check for non-aggregated columns in queries with aggregate function, but without
GROUP BY was treating all the parts of the query as if they are in the SELECT list.
Fixed by ignoring the non-aggregated fields in the WHERE clause.

mysql-test/r/func_group.result:
  Bug #39656: test case
mysql-test/t/func_group.test:
  Bug #39656: test case
sql/sql_select.cc:
  Bug #39656: ignore the new non-aggregated column refs in a WHERE
  by saving the state so far and then adding only the new values of the other
  parts of the bitmask.

the problem is the same as reported in bug#20835,
so the fix is backport of bug#20835 patch.


mysql-test/r/subselect.result:
  test result
mysql-test/t/subselect.test:
  test case

returns truncated results

Problem: performig conversion from {INT, DECIMAL, REAL} to CHAR
we incorrectly set its max length in some cases that may lead
to truncated results returned.

Fix: properly set CONVERT({INT, DECIMAL, REAL}, CHAR) result's
max length.


mysql-test/r/ctype_utf8.result:
  Fix for bug#36772: When using UTF8, CONVERT with GROUP BY
  returns truncated results
    - test result.
mysql-test/t/ctype_utf8.test:
  Fix for bug#36772: When using UTF8, CONVERT with GROUP BY
  returns truncated results
    - test case.
sql/item_timefunc.cc:
  Fix for bug#36772: When using UTF8, CONVERT with GROUP BY
  returns truncated results
    - calculating Item_char_typecast::max_length use initial
  argument's charset mbmaxlen instead of from_cs->mbmaxlen,
  as from_cs may differ in some case (see comment above).

Problem: memory leak occurs when we open a federated table
that has its share in the hash.

Fix: free not used memory.

Note: the fix should NOT be merged to 5.1 (the code changed).


sql/ha_federated.cc:
  Fix for bug#40875: Memory leak in FEDERATED handler
    - free memory (tmp_share.scheme) allocated in the parse_url()
  if it isn't used anymore.

The test itself is not faulty. The testcase timeout
problem happens if this IMHO mid size resource
(space in vardir, virtual memory, amount of disk I/O)
consuming test meets a weak (excessive disk I/O caused
by parallel applications or paging) testing box.

The modifications:
- Move the most time and disk I/O consuming subtest
  for Bug 1820 into its own script (multi_update2)
  This will reduce the likelihood that we exceed the
  testcase timeout.
- Replace error numbers with error names
- Minor improvements of the formatting

- 

      
When a CSV file contained comma separated elements 
that were not enclosed in quotes, it was causing the
mysql server to crash.
      
The old algorithm that parsed the content of a row in
mysql 5.0 was assuming that the values of the fields
in a .CSV file will be enclosed in quotes and will be
separated by commas.

This was causing the old algorithm to fail when the 
content of the file resembled the following
3,"sans quotes"
The CSV engine that is part of mysql 5.0 was expecting
the above to be
"3","sans quotes"
      
The above is just one example of where the engine was
failing for what would be recognized as a valid .CSV 
file content otherwise.
      
The proposed fix changes the old algorithm being used
to parse rows from the .CSV file to handle two separate
cases

1) When the current field of the row is enclosed in quotes
2) When the current field of the row is not enclosed in 
   quotes

mysql-test/r/csv.result:
  Contains additional test output corresponding to the new 
  tests added.
mysql-test/t/csv.test:
  Contains additional tests for testing the behaviour of the CSV 
  storage engine when the fields are not enclosed in quotes.
sql/examples/ha_tina.cc:
  Changes the parsing logic of the rows in a CSV file to account for
  fields that are not enclosed in quotes.

Item_func_div didn't calculate the precision of the result properly.
  The result of 5/0.0001 is 5000 so we have to add decimals of the divisor
  to the planned precision.

per-file comments:
  mysql-test/r/type_newdecimal.result
Bug#31616 div_precision_increment description looks wrong
    test result fixed

  mysql-test/t/type_newdecimal.test
Bug#31616 div_precision_increment description looks wrong
    test case

  sql/item_func.cc
Bug#31616 div_precision_increment description looks wrong
    precision must be increased with args[1]->decimals parameter

            missing after downgrade

Obsolete arc/ directory and view .frm file backup support
has been removed by the patch for bug 17823. However, that
bugfix caused a problem with "live downgrades" of the
server: if we rename some view 4 times under 5.1.29/5.0.72
and then try to rename it under 5.1.28/5.0.70 on the same
database, the server fails with a error:

  query 'RENAME TABLE ... TO ...' failed: 6: Error on
  delete of '....frm-0001' (Errcode: 2)

Also .frm file of that view may be lost (renamed to .frm~).

The server failed because it tried to rename latest 3
backup .frm files renaming the view: the server used an
integer value of the "revision" field of .frm file to
extract those file names. After the fix for bug 17823 those
files were not created/maintained any more, however the
"revision" field was incremented as usual. So, the server
failed renaming non existent files.

This fix solves the problem by removing the support for
"revision" .frm file field:
1. New server silently ignores existent "revision" fields
   in old .frm files and never write it down;
2. Old server assumes, that missing "revision" field in new
   .frm files means default value of 0.
3. Accordingly to the fix for bug 17823 the new server
   drops arc/ directory on alter/rename view, so after
   "live downgrade" old server begins maintenance of the
   arc/ directory from scratch without conflicts with .frm
   files.


sql/parse_file.cc:
  Bug #40021: Renaming view fails, archived .frm for view is
              missing after downgrade
  
  1. static write_parameter(): the old_version parameter
     and the section for FILE_OPTIONS_REV have been re moved.
  2. write_parameter(): the max_versions parameter has been
     removed;
  3. sql_create_definition_file(): removal of dead code;
  4. rename_in_schema_file(): revision and num_view_backups
     parameters and dead code have been removed;
  5. File_parser::parse(): FILE_OPTIONS_REV section has been
     removed.
sql/parse_file.h:
  Bug #40021: Renaming view fails, archived .frm for view is
              missing after downgrade
  
  1. The FILE_OPTIONS_REV constant has been removed.
  2. sql_create_definition_file and rename_in_schema_file
     functions: obsolete versions, revision and
     num_view_backups parameters have been removed.
sql/sql_db.cc:
  Bug #40021: Renaming view fails, archived .frm for view is
              missing after downgrade
  
  Commentary update.
sql/sql_trigger.cc:
  Bug #40021: Renaming view fails, archived .frm for view is
              missing after downgrade
  
  sql_create_definition_file() calls have been updates to
  new parameter lists.
sql/sql_view.cc:
  Bug #40021: Renaming view fails, archived .frm for view is
              missing after downgrade
  
  1. The mysql_create_view function code is used for both
     CREATE VIEW and ALTER queries, but query cache is
     necessary for ALTER command only. Check for a non first
     view revision has been replaced with a direct check for
     ALTER query.
  2. The num_view_backups global constant has been removed.
  3. view_parameters: the "revision" .frm field support has
     been removed.
  4. sql_create_definition_file and rename_in_schema_file
     function calls have been updates to new parameter lists.
sql/table.h:
  Bug #40021: Renaming view fails, archived .frm for view is
              missing after downgrade
  
  TABLE_LIST: the revision field has been removed.

tables can cause server to crash!

The bug will be fixed by patch for #34779: "crash in checksum table
on federated tables with blobs containing nulls"

Only a test case commited.


mysql-test/r/federated.result:
  Test case for bug #34774: key prefix on text field in federated 
  tables can cause server to crash!
    - test result.
mysql-test/t/federated.test:
  Test case for bug #34774: key prefix on text field in federated 
  tables can cause server to crash!
    - test case.

when InnoDB frm file corruption

Problem: mysqlcheck runs 'SHOW FULL TABLE' queries to get table lists.
The query may fail for some reasons (e.g. null .frm file) then
mysqlcheck doesn't process the database tables.

Fix: try to run 'SHOW TABLES' if 'SHOW FULL TABLES' failed.


client/mysqlcheck.c:
  Fix for bug#37527: mysqlcheck fails to report entire database 
  when InnoDB frm file corruption
    - run "SHOW TABLES" query if "SHOW /*!50002 FULL*/ TABLES" failed;
    - print error info if both failed.
mysql-test/r/mysqlcheck.result:
  Fix for bug#37527: mysqlcheck fails to report entire database 
  when InnoDB frm file corruption
    - test result.
mysql-test/t/mysqlcheck.test:
  Fix for bug#37527: mysqlcheck fails to report entire database 
  when InnoDB frm file corruption
    - test case.