As the result of DOUBLE claculations can be bigger
than DBL_MAX constant we use in code, we shouldn't use this constatn
as a biggest possible value.
Particularly the rtree_pick_key function set 'min_area= DBL_MAX' relying
that any rtree_area_increase result will be less so we return valid
key. Though in rtree_area_increase function we calculate the area
of the rectangle, so the result can be 'inf' if the rectangle is
huge enough, which is bigger than DBL_MAX.

Code of the rtree_pick_key modified so we always return a valid key.


myisam/rt_index.c:
  Bug #30286 spatial index cause corruption and server crash!
  
  always set the best_key with the first key we get, so we always return
  somthing valid.
myisam/rt_mbr.c:
  Bug #30286 spatial index cause corruption and server crash!
  
  function comment extended
mysql-test/r/gis-rtree.result:
  Bug #30286 spatial index cause corruption and server crash!
  test result
mysql-test/t/gis-rtree.test:
  Bug #30286 spatial index cause corruption and server crash!
  test case

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-4.1-build

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-4.1

into  trift2.:/MySQL/M41/push-4.1

into  production.mysql.com:/usersnfs/jperkin/bk/trees/build/mysql-4.1

  Fix typo in usage.


myisam/myisamchk.c:
  Fix typo in usage.

into  ramayana.hindu.god:/home/tsmith/m/bk/maint/41

into  ramayana.hindu.god:/home/tsmith/m/bk/maint/41

into  ramayana.hindu.god:/home/tsmith/m/bk/maint/41

into  production.mysql.com:/usersnfs/jperkin/bk/mysql-4.1-maint

which does not work.  Removing these attempted privileges makes
this identical to option 5 so remove it completely.  The spirit
of the program appears to be aimed at database privileges, so do
not add another option for granting global privileges as it may
be unexpected.  Fixes bug#14618 (same as previous patch, this
time applied to -maint tree).


scripts/mysql_setpermission.sh:
  Option 6 tries to apply global privileges at the database
  level which does not work - remove it.

into  mysql.com:/home/hf/work/29717/my41-29717


sql/sql_select.cc:
  Auto merged

 SELECT statement itself returns empty.

As a result of this bug 'SELECT AGGREGATE_FUNCTION(fld) ... GROUP BY'
can return one row instead of an empty result set.

When GROUP BY only has fields of constant tables
(with a single row), the optimizer deletes the group_list.
After that we lose the information about whether we had an
GROUP BY statement. Though it's important
as SELECT min(x) from empty_table; and
   SELECT min(x) from empty_table GROUP BY y; have to return
different results - the first query should return one row,
second - an empty result set.
So here we add the 'group_optimized_away' flag to remember this case
when GROUP BY exists in the query and is removed
by the optimizer, and check this flag in end_send_group()


mysql-test/r/group_by.result:
  Bug #29717 INSERT INTO SELECT inserts values even if
   SELECT statement itself returns empty.
  
  test result
mysql-test/r/insert_select.result:
  Bug #29717 INSERT INTO SELECT inserts values even if
   SELECT statement itself returns empty.
  
  test result
mysql-test/t/group_by.test:
  Bug #29717 INSERT INTO SELECT inserts values even if
   SELECT statement itself returns empty.
  
  This is additional testcase that is more basic than the
  original bug's testcase and has the same reason.
mysql-test/t/insert_select.test:
  Bug #29717 INSERT INTO SELECT inserts values even if
   SELECT statement itself returns empty.
  
  test case
sql/sql_select.cc:
  Bug #29717 INSERT INTO SELECT inserts values even if
   SELECT statement itself returns empty.
  
  Remember the 'GROUP BY was optimized away' case in the JOIN::group_optimized
  and check this in the end_send_group()
sql/sql_select.h:
  Bug #29717 INSERT INTO SELECT inserts values even if
   SELECT statement itself returns empty.
  
  JOIN::group_optimized member added to remember the 'GROUP BY optimied away'
  case

  Backport of correction for Mac OS X build problem, global variable not
  initiated is "common" and can't be used in shared libraries, unless
  special flags are used (bug#26218)


mysys/my_pthread.c:
  Backport of correction for Mac OS X build problem, global variable not
  initiated is "common" and can't be used in shared libraries, unless
  special flags are used (bug#26218)

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-4.1

into  debian.(none):/M41/push-4.1

to 150 or 107 characters for those messages which are generated
by the embedded server during release builds.

This fixes bug#16635:
   Error messages wrong: absolute path names, "%s" format code

See the bug report or the changelog for "sql/share/english/errmsg.txt"
for instructions how to do that with other languages, 
even at the customer site, and for the restrictions to keep.


sql/share/english/errmsg.txt:
  The embedded server uses absolute path names in its error messages,
  in the release build environment these exceed the 64 character limit
  which the format strings for the error messages impose (bug#16635).
  
  But when the messages are output, the server does the "printf()" 
  internally in a 256 character buffer; the constant text and the
  expanded variables (strings, error number) must fit into this.
  
  (If the buffer would overflow, a format specification will not be
  expanded but just copied with its code, and the message output
  will just contain '%s' or '%d' where a value is expected.)
  
  So the string lengths are increased to 150 characters in those messages
  which are issued by the embedded server during release tests
  and contain 1 (one) path name,
  but only to 107 in the "rename" message which contains 2 (two).
  
  This solves bug#16635 for the release builds.
  
  For other languages used by OEM customers, similar fixes may be needed,
  but we cannot test them.
  
  These fixes can be done even in a binary installation at the customer site
  by following these steps:
     cd <<install-root>>/share
     $EDITOR <<lang>>/errmsg.txt
     ../../bin/comp_err -C./charsets/ <<lang>>/errmsg.txt <<lang>>/errmsg.sys
  and then restarting the server.

into  mysql.com:/home/hf/work/29494/my41-29494

This bug manifested itself for join queries with GROUP BY and HAVING clauses
whose SELECT lists contained DISTINCT. It occurred when the optimizer could
deduce that the result set would have not more than one row.
The bug could lead to wrong result sets for queries of this type because
HAVING conditions were erroneously ignored in some cases in the function
remove_duplicates.   


mysql-test/r/having.result:
  Added a test case for bug #29911.
mysql-test/t/having.test:
  Added a test case for bug #29911.

unpack_fields() didn't expect NULL_LENGHT in the field's descriptions.
In this case we get NULL in the resulting string so cannot use
strdup_root to make a copy of it.
strdup_root changed with strmake_root as it's NULL-safe


sql-common/client.c:
  Bug #29494 Field packet with NULL fields crashes libmysqlclient
  
  strdup_root changed with strmake_root in unpack_fields()

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-4.1

into  ramayana.hindu.god:/home/tsmith/m/bk/maint/41

into  sin.intern.azundris.com:/home/tnurnberg/27198/41-27198


sql/mysql_priv.h:
  Bug #27198: Error returns from time() are ignored
  
  manual merge
sql/sql_class.h:
  Bug #27198: Error returns from time() are ignored
  
  manual merge

into  chilla.local:/home/mydev/mysql-4.1-axmrg

gettimeofday() can fail and presumably, so can time().
Keep an eye on it.

Since we have no data on this at all so far, we just
retry on failure (and log the event), assuming that
this is just an intermittant failure. This might of
course hang the threat until we succeed. Once we know
more about these failures, an appropriate more clever
scheme may be picked (only try so many times per thread,
etc., if that fails, return last "good" time() we got or
some such).  Using sql_print_information() to log as this
probably only occurs in high load scenarios where the debug-
trace likely is disabled (or might interfere with testing
the effect).  No test-case as this is a non-deterministic
issue.


sql/mysql_priv.h:
  Bug#27198: Error returns from time() are ignored
  
  move declarations for log.cc to before inclusion of
  sql_class.h as we now use sql_print_information() in
  there.
sql/sql_class.h:
  Bug#27198: Error returns from time() are ignored
  
  gettimeofday() can fail and presumably, so can time().
  Keep an eye on it.

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-4.1

into  sita.local:/Users/tsmith/m/bk/maint/41

into  chilla.local:/home/mydev/mysql-4.1-axmrg

into  chilla.local:/home/mydev/mysql-4.1-axmrg

into  gleb.loc:/home/uchum/work/bk/4.1-opt

into  sita.local:/Users/tsmith/m/bk/maint/41

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-4.1

into  anubis.xiphis.org:/usr/home/antony/work/mysql-4.1-engines.merge

into  chilla.local:/home/mydev/mysql-4.1-axmrg

Dropping an user defined function may cause server crash in
case this function is still in use by another thread.

The problem was that our hash implementation didn't update
hash link list properly when hash_update() was called.


mysys/hash.c:
  The following requirement wasn't met by hash_update() function
  causing corruption of hash links list:
  
  After a record was unlinked from the old chain during update, it
  holds random position. By the chance this position is equal to
  position for the first element in the new chain. That means
  updated record is the only record in the new chain.

into  maint1.mysql.com:/data/localhome/tsmith/bk/maint/41

into  gleb.loc:/home/uchum/work/bk/4.1-opt

  Test case update for bug #29294.


mysql-test/t/loaddata.test:
  Test case update for bug #29294.
mysql-test/r/loaddata.result:
  Test case update for bug #29294.

  Windows compilation error fix.


sql/sql_class.cc:
  Windows compilation error fix.

The `SELECT 'r' INTO OUTFILE ... FIELDS ENCLOSED BY 'r' ' statement
encoded the 'r' string to a 4 byte string of value x'725c7272'
(sequence of 4 characters: r\rr).
The LOAD DATA statement decoded this string to a 1 byte string of
value x'0d' (ASCII Carriage Return character) instead of the original
'r' character.
The same error also happened with the FIELDS ENCLOSED BY clause
followed by special characters: 'n', 't', 'r', 'b', '0', 'Z' and 'N'.

NOTE 1: This is a result of the undocumented feature: the LOAD DATA INFILE
recognises 2-byte input sequences like \n, \t, \r and \Z in addition
to documented 2-byte sequences: \0 and \N. This feature should be
documented (here backspace character is a default ESCAPED BY character,
in the real-life example it may be any ESCAPED BY character).

NOTE 2, changed behaviour:
Now the `SELECT INTO OUTFILE' statement with the `FIELDS ENCLOSED BY'
clause followed by one of: 'n', 't', 'r', 'b', '0', 'Z' or 'N' characters
encodes this special character itself by doubling it ('r' --> 'rr'),
not by prepending it with an escape character.


sql/sql_class.h:
  Fixed bug #29294.
  The ESCAPE_CHARS macro constant is defined to enumerate
  symbolic names of espace-sequences like  '\n', '\t' etc.
  The select_export::is_ambiguous_field_sep field has been added
  to distinguish special values of the field_sep field from
  another values (see ESCAPE_CHARS).
sql/sql_class.cc:
  Fixed bug #29294.
  The select_export::send_data method has been modified to
  encode special values of the field_sep field by
  doubling of those values instead of prepending them with a
  value of the escape_char field.
  Example: The SELECT 'r' INTO OUTFILE FIELDS ENCLOSED BY 'r'
  now produces the 'rr' output string instead of x'5c72'
  (i.e. instead of sequence of 2 bytes: \ and r).
sql/sql_load.cc:
  Fixed bug #29294.
  Added commentary for the READ_INFO::unescape method.
mysql-test/t/loaddata.test:
  Updated test case for bug #29294.
mysql-test/r/loaddata.result:
  Updated test case for bug #29294.