Bug#33675: Usage of an uninitialized memory by filesort in a subquery caused
  server crash.
  Free smaller buffer before allocating bigger one.

into  moonbone.local:/work/33675-bug-5.0-opt-mysql

into  magare.gmz:/home/kgeorge/mysql/autopush/B33133-5.0-opt

When resolving references we need to take into consideration
the view "fields" and allow qualified access to them.
Fixed by extending the reference resolution to process view
fields correctly.

server crash.

The filesort implementation has an optimization for subquery execution which
consists of reusing previously allocated buffers. In particular the call to
the read_buffpek_from_file function might be skipped when a big enough buffer
for buffer descriptors (buffpeks) is already allocated. Beside allocating
memory for buffpeks this function fills allocated buffer with data read from
disk. Skipping it might led to using an arbitrary memory as fields' data and
finally to a crash.

Now the read_buffpek_from_file function is always called. It allocates
new buffer only when necessary, but always fill it with correct data.

into  magare.gmz:/home/kgeorge/mysql/autopush/B33256-5.0-opt

 w/ Field_date instead of Field_newdate
  
Field_date was still used in temp table creation.
Fixed by using Field_newdate consistently throughout the server
except when reading tables defined with older MySQL version.
No test suite is possible because both Field_date and Field_newdate
return the same values in all the metadata calls. 

into  mysql.com:/misc/mysql/31990/50-31990

into  linux-st28.site:/home/martin/mysql/src/bug32848/my50-bug32848

Warnings elimination

into  mysql.com:/misc/mysql/31990/50-31990

into  linux-st28.site:/home/martin/mysql/src/bug32848/my50-bug32848

into  magare.gmz:/home/kgeorge/mysql/autopush/B19390-5.0-opt

The checks in the test for bug #12480 were too wide and
made the test to depend on the procedures and triggers
present in the server.
Corrected the test to check only for the procedure and 
trigger it creates.

into  mysql.com:/misc/mysql/32770/50-32770

into  mysql.com:/misc/mysql/31752_/50-31752_

into  mysql.com:/misc/mysql/31752_/50-31752_

fix test program

into  mysql.com:/misc/mysql/32770/50-32770

into  mysql.com:/misc/mysql/31752_/50-31752_

into  mysql.com:/misc/mysql/31752_/50-31752_

into  mysql.com:/misc/mysql/32770/50-32770

into  linux-st28.site:/home/martin/mysql/src/bug32798-united/my50-bug32798-united-push

into  linux-st28.site:/home/martin/mysql/src/bug32858/my50-bug32858-push

into  linux-st28.site:/home/martin/mysql/src/bug32798-united/my50-bug32798-united-push

into  olga.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug27848

In a union without braces, the order by at the end is applied to the 
overall union. It therefore should not interfere with the individual
select parts of the union.

Fixed by changing our parser rules appropriately.

with null values

For queries containing GROUP_CONCAT(DISTINCT fields ORDER BY fields), there 
was a limitation that the DISTINCT fields had to be the same as ORDER BY 
fields, owing to the fact that one single sorted tree was used for keeping 
track of tuples, ordering and uniqueness. Fixed by introducing a second 
structure to handle uniqueness so that the original structure has only to 
order the result.

into  mysql.com:/home/gluh/MySQL/Merge/5.0-opt

into  mysql.com:/home/gluh/MySQL/Merge/5.0-opt

into  mysql.com:/home/psergey/mysql-5.0-bug32198

- Make conditions like "date_col $CMP$ 'datetime-const'" range-sargable

into  mysql.com:/home/gluh/MySQL/Merge/4.1-opt

subselects into account

It is forbidden to use the SELECT INTO construction inside UNION statements
unless on the last SELECT of the union. The parser records whether it 
has seen INTO or not when parsing a UNION statement. But if the INTO was
legally used in an outer query, an error is thrown if UNION is seen in a
subquery. Fixed in 5.0 by remembering the nesting level of INTO tokens and 
mitigate the error unless it collides with the UNION.

Fixed case of comment.

into  stella.local:/home2/mydev/mysql-5.0-axmrg

There were two problems when inferring the correct field types resulting from
UNION queries.
- If the type is NULL for all corresponding fields in the UNION, the resulting 
  type would be NULL, while the type is BINARY(0) if there is just a single 
  SELECT NULL.
- If one SELECT in the UNION uses a subselect, a temporary table is created
  to represent the subselect, and the result type defaults to a STRING type,
  hiding the fact that the type was unknown(just a NULL value).
Fixed by remembering whenever a field was created from a NULL value and pass
type NULL to the type coercion if that is the case, and creating a string field
as result of UNION only if the type would otherwise be NULL.