Decimals with float, double and decimal now works the following way:
- DECIMAL_NOT_SPECIFIED is used when declaring DECIMALS without a firm number
of decimals. It's only used in asserts and my_decimal_int_part.
- FLOATING_POINT_DECIMALS (31) is used to mark that a FLOAT or DOUBLE
was defined without decimals. This is regarded as a floating point value.
- Max decimals allowed for FLOAT and DOUBLE is FLOATING_POINT_DECIMALS-1
- Clients assumes that float and double with decimals >= NOT_FIXED_DEC are
floating point values (no decimals)
- In the .frm decimals=FLOATING_POINT_DECIMALS are used to define
floating point for float and double (31, like before)
To ensure compatibility with old clients we do:
- When storing float and double, we change NOT_FIXED_DEC to
FLOATING_POINT_DECIMALS.
- When creating fields from .frm we change for float and double
FLOATING_POINT_DEC to NOT_FIXED_DEC
- When sending definition for a float/decimal field without decimals
to the client as part of a result set we convert NOT_FIXED_DEC to
FLOATING_POINT_DECIMALS.
- variance() and std() has changed to limit the decimals to
FLOATING_POINT_DECIMALS -1 to not get the double converted floating point.
(This was to preserve compatiblity)
- FLOAT and DOUBLE still have 30 as max number of decimals.
Bugs fixed:
variance() printed more decimals than we support for double values.
New behaviour:
- Strings now have 38 decimals instead of 30 when converted to decimal
- CREATE ... SELECT with a decimal with > 30 decimals will create a column
with a smaller range than before as we are trying to preserve the number of
decimals.
Other changes
- We are now using the obsolete bit FIELDFLAG_LEFT_FULLSCREEN to specify
decimals > 31
- NOT_FIXED_DEC is now declared in one place
- For clients, NOT_FIXED_DEC is always 31 (to ensure compatibility).
On the server NOT_FIXED_DEC is DECIMAL_NOT_SPECIFIED (39)
- AUTO_SEC_PART_DIGITS is taken from DECIMAL_NOT_SPECIFIED
- DOUBLE conversion functions are now using DECIMAL_NOT_SPECIFIED instead of
NOT_FIXED_DEC
Since a query can now refer to the same temporary table
multiple times, find_dup_table()/find_table_in_list()
have been updated to also consider this new possibility.
Temporary table being created by outer statement
should not be visible to inner statement. And if
inner statement creates a table with same name.
The whole statement should fail with
ER_TABLE_EXISTS_ERROR.
Implemented by temporarily de-linking the TABLE_SHARE
being created by outer statement so that it remains
hidden to the inner statement.
mysqld maintains a list of TABLE objects for all temporary
tables created within a session in THD. Here each table is
represented by a TABLE object.
A query referencing a particular temporary table for more
than once, however, failed with ER_CANT_REOPEN_TABLE error
because a TABLE_SHARE was allocate together with the TABLE,
so temporary tables always had only one TABLE per TABLE_SHARE.
This patch lift this restriction by separating TABLE and
TABLE_SHARE objects and storing TABLE_SHAREs for temporary
tables in a list in THD, and TABLEs in a list within their
respective TABLE_SHAREs.
Allowing GROUP_CONCAT(... ORDER BY ..) in queries with ROLLUP.
The story of the related code:
1. The original patch from Wax
commit: 0b505fb437
date: Tue Mar 18 03:07:40 2003
opt_gorder_clause reused the regular order_clause,
which already had some protection against ROLLUP queries:
order_clause:
ORDER_SYM BY
{
LEX *lex=Lex;
if (lex->current_select->linkage != GLOBAL_OPTIONS_TYPE &&
lex->current_select->select_lex()->olap !=
UNSPECIFIED_OLAP_TYPE)
{
net_printf(lex->thd, ER_WRONG_USAGE,
"CUBE/ROLLUP",
"ORDER BY");
YYABORT;
}
} order_list;
The assumption that ORDER BY in group_concat() had to have
the same ROLLUP restriction (with order_clause) was wrong.
Moreover, GROUP_CONCAT() in select_item_list was not affected
by this restriction, because WITH ROLLUP goes after
select_item_list and therefore sel->olap is always equal
to UNSPECIFIED_OLAP_TYPE during select_item_list.
GROUP BY was not affected for two reasons:
- it goes before WITH ROLLUP and sel->olap is still
UNSPECIFIED_OLAP_TYPE
- Aggregate functions like AVG(), GROUP_CONCAT() in GROUP BY
are not allowed
So only GROUP_CONCAT() in HAVING and ORDER BY clauses
were erroneously affected by this restriction.
2. Bug#27848 rollup in union part causes error with order of union
commit: 3f6073ae63
Author: unknown <igor@olga.mysql.com> 2007-12-15 01:42:46
The condition in the ROLLUP protection code became more complex.
Note, opt_gconcat_order still reused the regular order_clause.
3. Bug#16347426 ASSERTION FAILED: (SELECT_INSERT &&
!TABLES->NEXT_NAME_RESOLUTION_TABLE) || !TAB
commit: 2d83663380
author: Chaithra Gopalareddy <chaithra.gopalareddy@oracle.com>
date: 2013-04-14 06:00:49
opt_gorder_clause was refactored not to use order_clause and
to collect information directly to select->gorder_list.
The ROLLUP protection code was duplicated from order_clause
to the new version of opt_gorder_clause.
- Validate the specified wsrep_start_position value by also
checking the return status of wsrep->sst_received. This also
ensures that changes in wsrep_start_position is not allowed
when the node is not in JOINING state.
- Do not allow decrease in seqno within same UUID.
- The initial checkpoint in SEs should be [0...:-1].
1. Moving the "| get_select_lex_derived select_derived_init" part of
select_derived into a separate new rule derived_query_specification.
2. Using derived_query_specification directly in select_derived_union
rather than in select_derived.
3. Moving the sequence "opt_order_clause opt_limit_clause opt_select_lock_type"
from select_derived2 to select_derived_union,
after derived_query_specification.
Effectively, the parser now does not go through the sequence
"opt_order_clause opt_limit_clause ... opt_union_order_or_limit" any more.
This fixes the problem with double LIMIT clause and removes 2 shift/reduce
conflicts.
This change refactors the "table_expression" rule in sql_yacc.yy.
Queries with subselects and derived tables, as well as "CREATE TABLE ... SELECT"
now return syntax error instead of "Incorrect usage of PROCEDURE and ...".
Checksum implementations contain optimizations for calculating
checksums of larger blocks of memory.
This optimization calls my_checksum on a larger block of memory
rather than calling on multiple adjacent memory as its going though
the table columns for each table row.
When the specification of a WITH table referred to a view
that used a based table with the same name as the WITH table
the server went into an infinite loop because it erroneously
resolved the reference to the base table as the reference to
the WITH table.
With tables used in a view cannot be searched for beyond the
scope the view.
When join output is just one row, we still need to compute window
function values for it. We could skip invoking filesort for it,
but it doesn't seem to be worth it to do such optimization.
Make Frame_range_current_row_bottom to take into account partition bounds.
Other partition bounds that could potentially hit the end of partition are
Frame_range_n_bottom, Frame_n_rows_following, Frame_unbounded_following,
and they all had end-of-partition protection.
To simplify the code, factored out end-of-partition checks into
class Partition_read_cursor.
This bug revealed a serious problem: if the same partition list
was used in two window specifications then the temporary table created
to calculate window functions contained fields for two identical
partitions. This problem was fixed as well.
When ordering by a column and partitioning by another, we must reset the
peer_tracker for dense_rank, regardless if the value for the order
column changes or not.
Example:
select a, b, dense_rank() over (partition by b order by a)
a | b | dense_rank
----------------------
1 | p1 | 1
2 | p1 | 2
2 | p2 | 1 // Here, without this fix we returned 0.
2 | p2 | 2 // And 1 here.
The bug was caused by a weird behaviour in test_if_group_changed, not
returning true when testing for the first time after initializing
the Cached_item list.
