Removed wrong patch to fix DATE BETWEEN TIMESTAMP1 AND TIMESTAMP2

Some simple optimizations


Docs/manual.texi:
  Updted how binary log works
mysql-test/mysql-test-run.sh:
  Added usage of --port to mysqltest
mysql-test/r/func_test.result:
  Moved test of datetime comparison to func_time
mysql-test/r/func_time.result:
  New test
mysql-test/t/func_test.test:
  Moved test of datetime comparison to func_time
mysql-test/t/func_time.test:
  Test of DATE BETWEEN TIMESTAMPS
sql/field.h:
  Removed wrong patch
sql/item_cmpfunc.cc:
  Removed wrong patch
  (Need to be fixed by taking into account all arguments to between)
sql/lock.cc:
  Removed call to current_thd
sql/set_var.cc:
  Don't show 'socket' variable if sockets are not used
sql/sql_base.cc:
  Simple optimisation

1 files changed, 9 insertions, 5 deletions

diff --git a/Docs/manual.texi b/Docs/manual.texi
index 1e1c080d6b3..049f4099eef 100644
--- a/Docs/manual.texi
+++ b/Docs/manual.texi
@@ -23510,17 +23510,21 @@ will be logged in the execution order.
 Updates to non-transactional tables are stored in the binary log
 immediately after execution.  For transactional tables such as @code{BDB}
 or @code{InnoDB} tables, all updates (@code{UPDATE}, @code{DELETE}
-or @code{INSERT}) that change tables are cached until a @code{COMMIT}.
+or @code{INSERT}) that change tables are cached until a @code{COMMIT} command
+is sent to the server. At this point mysqld writes the whole transaction to
+the binary log before the @code{COMMIT} is executed.
 Every thread will, on start, allocate a buffer of @code{binlog_cache_size}
 to buffer queries.  If a query is bigger than this, the thread will open
-a temporary file to handle the bigger cache.  The temporary file will
+a temporary file to store the transcation.  The temporary file will
 be deleted when the thread ends.
 
-The @code{max_binlog_cache_size} can be used to restrict the total size used
-to cache a multi-query transaction.
+The @code{max_binlog_cache_size} (default 4G) can be used to restrict
+the total size used to cache a multi-query transaction.  If a transaction is
+bigger than this it will fail and roll back.
 
 If you are using the update or binary log, concurrent inserts will
-not work together with @code{CREATE ... SELECT} and @code{INSERT ... SELECT}.
+be converted to normal inserts when using @code{CREATE ... SELECT} and
+@code{INSERT ... SELECT}.
 This is to ensure that you can recreate an exact copy of your tables by
 applying the log on a backup.