Additional result file update

join view in sql_safe_updates mode. 

This bug was unexpectedly fixed along with bug 
number 49534. This patch contains only the test
case.

BUG#51342 - more xid crashing

Restore autocommit variable by supplying explicit value.

mysql-test/r/xa.result:
  Restore autocommit variable by supplying explicit value.
mysql-test/t/xa.test:
  Restore autocommit variable by supplying explicit value.

(regression)

Problem was that partition pruning did not exclude the
last partition if the range was beyond it
(i.e. not using MAXVALUE)

Fix was to not include the last partition if the
partitioning function value was not within the partition
range.

mysql-test/r/partition_innodb.result:
  Bug#51830: Incorrect partition pruning on range partition
  (regression)
  
  Updated result
mysql-test/r/partition_pruning.result:
  Bug#51830: Incorrect partition pruning on range partition
  (regression)
  
  Updated result
mysql-test/t/partition_innodb.test:
  Bug#51830: Incorrect partition pruning on range partition
  (regression)
  
  Added test for pruning in InnoDB, since it does not show
  for MyISAM due to 'Impossible WHERE noticed after reading
  const tables'.
mysql-test/t/partition_pruning.test:
  Bug#51830: Incorrect partition pruning on range partition
  (regression)
  
  Added test
sql/sql_partition.cc:
  Bug#51830: Incorrect partition pruning on range partition
  (regression)
  
  Also increase the partition id if not inside the last partition
  (and no MAXVALUE is defined).
  
  Added comments and DBUG_ASSERT.

SET autocommit=1 while XA transaction is active may
cause various side effects, including memory corruption
and server crash.

The problem is that SET autocommit=1 and further queries
attempt to commit local transaction, whereas XA transaction
is still active.

As local and XA transactions are mutually exclusive, this
patch forbids enabling autocommit mode while XA transaction
is active.

mysql-test/r/xa.result:
  A test case for BUG#51342.
mysql-test/t/xa.test:
  A test case for BUG#51342.
sql/set_var.cc:
  Forbid enabling autocommit mode while XA transaction is
  active.

MySQL uses two source layouts when building : the bzr 
layout and the source package layout.
The previous fix for bug 35250 contained 1 change that is
valid for both modes and a number of changes that are valid
only for the bzr source layout.
The important thing was to fix the source package layout.
And for this the change in configure.in was sufficient.
It's not trivial (and not requested by this bug) to support 
VPATH builds from the bzr trees.
This is why the other changes are reverted and the change to
fix the VPATH build for source distributions is left intact.

The test case added in previous patch missed a RESET MASTER on
test start up. Without it, showing binary log contents can
sometimes show spurious entries from previously executed tests,
ultimately causing test failure - result mismatch.

The test file was added in:
revid:luis.soares@sun.com-20100224190153-k0bpdx9abe88uoo2

This patch also moves the test case into binlog_innodb_row.test
file. This way we avoid having yet another test file,
binlog_row_innodb_truncate.test, whose only purpose is to host
one test case. This had been actually suggested during original
patch review, but somehow the binlog_innodb_row was missed when
searching for a file to host the test case.

mysql_upgrade was passing an non-initialized non-null tmpdir to create_temp_file() if no 
--tmpdir was specified. This prevents create_temp_file() from taking the system 
temporary file path and as a result mysql_upgrade was trying to open a file in a 
directory that it may not have write access to.
Fixed by making sure mysql_upgrade will pass a zero length temp dir string to 
create_temp_file() if no --tmpdir is specified.

output from HANDLER ... READ .. NEXT ...

The problem was that mysqltest could attempt to execute a
SHOW WARNINGS statement through a connection that was not
properly reaped, thus violating its own rules.

The solution is to skip SHOW WARNINGS if a connection has
not been properly repeaed.

client/mysqltest.cc:
  Skip SHOW WARNINGS if connection hasn't been reaped.

The problem is that not all column names retrieved from a SELECT
statement can be used as view column names due to length and format
restrictions. The server failed to properly check the conformity
of those automatically generated column names before storing the
final view definition on disk.

Since columns retrieved from a SELECT statement can be anything
ranging from functions to constants values of any format and length,
the solution is to rewrite to a pre-defined format any names that
are not acceptable as a view column name.

The name is rewritten to "Name_exp_%u" where %u translates to the
position of the column. To avoid this conversion scheme, define
explict names for the view columns via the column_list clause.
Also, aliases are now only generated for top level statements.

mysql-test/include/view_alias.inc:
  Add test case for Bug#40277
mysql-test/r/compare.result:
  Bug#40277: SHOW CREATE VIEW returns invalid SQL
mysql-test/r/group_by.result:
  Bug#40277: SHOW CREATE VIEW returns invalid SQL
mysql-test/r/ps.result:
  Bug#40277: SHOW CREATE VIEW returns invalid SQL
mysql-test/r/subselect.result:
  Bug#40277: SHOW CREATE VIEW returns invalid SQL
mysql-test/r/subselect3.result:
  Bug#40277: SHOW CREATE VIEW returns invalid SQL
mysql-test/r/type_datetime.result:
  Bug#40277: SHOW CREATE VIEW returns invalid SQL
mysql-test/r/union.result:
  Bug#40277: SHOW CREATE VIEW returns invalid SQL
mysql-test/r/view.result:
  Add test case result for Bug#40277
mysql-test/r/view_alias.result:
  Add test case result for Bug#40277
mysql-test/t/view_alias.test:
  Add test case for Bug#40277
sql/sql_view.cc:
  Check if auto generated column names are conforming. Also, the
  make_unique_view_field_name function is not used as it uses the
  original name to construct a new one, which does not work if the
  name is invalid.

The problem was that bits of the destructive equality propagation
optimization weren't being undone after the execution of a stored
program. Modifications to the parse tree that are based on transient
properties must be undone to enable the re-execution of stored
programs.

The solution is to cleanup any references to predicates generated
by the equality propagation during the execution of a stored program.

mysql-test/r/trigger.result:
  Add test case result for Bug#51650.
mysql-test/t/trigger.test:
  Add test case for Bug#51650.
sql/item.cc:
  Remove reference to a equality predicate.

Spatial indexes were not checking for out-of-record condition in
the handler next command when the previous command didn't found
rows.

Fixed by making the rtree index to check for end of rows condition
before re-using the key from the previous search.

Fixed another crash if the tree has changed since the last search.
Added a test case for the other error.

auto_increment on duplicate entry

The bug was that when INSERT_ID was used and the storage
engine was told to release any reserved but not used
auto_increment values, it set the highest auto_increment
value to INSERT_ID.

The fix was to check if the auto_increment value was forced
by user (INSERT_ID) or by slave-thread, i.e. not auto-
generated. So that it is only allowed to release generated
values.

mysql-test/r/partition_error.result:
  Bug#50392: insert_id is not reset for partitioned tables
  auto_increment on duplicate entry
  
  updated result
mysql-test/suite/parts/inc/partition_auto_increment.inc:
  Bug#50392: insert_id is not reset for partitioned tables
  auto_increment on duplicate entry
  
  Added test
mysql-test/suite/parts/r/partition_auto_increment_archive.result:
  Bug#50392: insert_id is not reset for partitioned tables
  auto_increment on duplicate entry
  
  Added result, note that archive does only allow increasing
  auto_increment values
mysql-test/suite/parts/r/partition_auto_increment_blackhole.result:
  Bug#50392: insert_id is not reset for partitioned tables
  auto_increment on duplicate entry
  
  Added result, note that blackhole accepts all inserts :)
mysql-test/suite/parts/r/partition_auto_increment_innodb.result:
  Bug#50392: insert_id is not reset for partitioned tables
  auto_increment on duplicate entry
  
  Added result, note that innodb rolls back inserts on error,
  but keeps the auto_increment value.
mysql-test/suite/parts/r/partition_auto_increment_memory.result:
  Bug#50392: insert_id is not reset for partitioned tables
  auto_increment on duplicate entry
  
  Added result, note that memory and myisam inserts all rows
  before the error.
mysql-test/suite/parts/r/partition_auto_increment_myisam.result:
  Bug#50392: insert_id is not reset for partitioned tables
  auto_increment on duplicate entry
  
  Added result, note that memory and myisam inserts all rows
  before the error.
mysql-test/suite/parts/r/partition_auto_increment_ndb.result:
  Bug#50392: insert_id is not reset for partitioned tables
  auto_increment on duplicate entry
  
  Added result, note that NDB does not seem to handle
  INSERT_ID as other engines. (Martin will look into it).
mysql-test/t/partition_error.test:
  Bug#50392: insert_id is not reset for partitioned tables
  auto_increment on duplicate entry
  
  Added test
sql/ha_partition.cc:
  Bug#50392: insert_id is not reset for partitioned tables
  auto_increment on duplicate entry
  
  If the next_insert_id comes from non generated (i.e
  forced by INSERT_ID or slave-thread) then we cannot
  lower the reserved auto_increment value, since it have
  not reserved any values.

Spatial indexes were not checking for out-of-record condition in
the handler next command when the previous command didn't found
rows.

Fixed by making the rtree index to check for end of rows condition
before re-using the key from the previous search.

Fixed another crash if the tree has changed since the last search.
Added a test case for the other error.

            consider clustered primary keys

Choosing a shortest index for the covering index scan,
the optimizer ignored the fact, that the clustered primary
key read involves whole table data.

The find_shortest_key function has been modified to
take into account that fact that a clustered PK has a
longest key of possible covering indices.


mysql-test/r/innodb_mysql.result:
  Test case for bug #39653.
mysql-test/t/innodb_mysql.test:
  Test case for bug #39653.
sql/sql_select.cc:
  Bug #39653: find_shortest_key in sql_select.cc does not
              consider clustered primary keys
  
  The find_shortest_key function has been modified to
  take into account that fact that a clustered PK has a
  longest key of possible covering indices.

 for ORDER BY on a TEXT or VARCHAR field" backported to 5.1.

This is *no* change in contents, the differences are formatting only
and an address update of the FSF. It continues to be Version 2, June 1991.