SELECT right instead of INSERT right was required for an insert into to a view.
This wrong behaviour appeared after the fix for bug #20989. Its intention was
to ask only SELECT right for all tables except the very first for a complex
INSERT query. But that patch has done it in a wrong way and lead to asking
a wrong access right for an insert into a view.
The setup_tables_and_check_access() function now accepts two want_access
parameters. One will be used for the first table and the second for other
tables.
This bug is a side-effect of bug fix#16377. NOW() is optimized in
BETWEEN to integer constants to speed up query execution. When view is being
created it saves already modified query and thus becomes wrong.
The agg_cmp_type() function now substitutes constant result DATE/TIME functions
for their results only if the current query isn't CREATE VIEW or SHOW CREATE
VIEW.
columns
Fixed confusing warning.
Quoting INSERT section of the manual:
----
Inserting NULL into a column that has been declared NOT NULL. For
multiple-row INSERT statements or INSERT INTO ... SELECT statements, the
column is set to the implicit default value for the column data type. This
is 0 for numeric types, the empty string ('') for string types, and the
"zero" value for date and time types. INSERT INTO ... SELECT statements are
handled the same way as multiple-row inserts because the server does not
examine the result set from the SELECT to see whether it returns a single
row. (For a single-row INSERT, no warning occurs when NULL is inserted into
a NOT NULL column. Instead, the statement fails with an error.)
----
This is also true for LOAD DATA INFILE. For INSERT user can specify
DEFAULT keyword as a value to set column default. There is no similiar
feature available for LOAD DATA INFILE.
When executing ALTER TABLE all the attributes of the view were overwritten.
This is contrary to the user's expectations.
So some of the view attributes are preserved now : namely security and
algorithm. This means that if they are not specified in ALTER VIEW
their values are preserved from CREATE VIEW instead of being defaulted.
When executing INSERT over a view with calculated columns it was assuming all
elements of the fields collection are actually Item_field instances.
This may not be true when inserting into a view and that view has columns that are
such expressions that allow updating (like setting a collation for example).
Corrected to access field information through the filed_for_view_update() function and
retrieve correctly the field info even for "update-friendly" non-Item_field items.
DESCRIBE returned the type BIGINT for a column of a view if the column
was specified by an expression over values of the type INT.
E.g. for the view defined as follows:
CREATE VIEW v1 SELECT COALESCE(f1,f2) FROM t1
DESCRIBE returned type BIGINT for the only column of the view if f1,f2 are
columns of the INT type.
At the same time DESCRIBE returned type INT for the only column of the table
defined by the statement:
CREATE TABLE t2 SELECT COALESCE(f1,f2) FROM t1.
This inconsistency was removed by the patch.
Now the code chooses between INT/BIGINT depending on the
precision of the aggregated column type.
Thus both DESCRIBE commands above returns type INT for v1 and t2.
When compiling INSERT statements the check whether columns are provided values
depends on the flag whether a field is used in that query (Field::query_id).
However the check for updatability of VIEW columns (check_view_insertability())
was calling fix_fields() and thus setting the Field::query_id even for the
view fields that are not referenced in the current INSERT statement.
So the correct check for columns without default values
( check_that_all_fields_are_given_values() ) is assuming that all the VIEW
columns were mentioned in the INSERT field list and was issuing no
warnings or errors.
Fixed check_view_insertability() to turn off the flag whether or not to set
Field::query_id (THREAD::set_query_id) before calling fix fields and restore
it when it's done.
The problem was that we restored SQL_CACHE, SQL_NO_CACHE flags in SELECT
statement from internal structures based on value set later at runtime, not
the original value set by the user.
The solution is to remember that original value.
When a CREATE TABLE command created a table from a materialized
view id does not inherit default values from the underlying table.
Moreover the temporary table used for the view materialization
does not inherit those default values.
In the case when the underlying table contained ENUM fields it caused
misleading error messages. In other cases the created table contained
wrong default values.
The code was modified to ensure inheritance of default values for
materialized views.
The convert_constant_item() function converts constant items to ints on
prepare phase to optimize execution speed. In this case it tries to evaluate
subselect which contains a derived table and is contained in a derived table.
All derived tables are filled only after all derived tables are prepared.
So evaluation of subselect with derived table at the prepare phase will
return a wrong result.
A new flag with_subselect is added to the Item class. It indicates that
expression which this item represents is a subselect or contains a subselect.
It is set to 0 by default. It is set to 1 in the Item_subselect constructor
for subselects.
For Item_func and Item_cond derived classes it is set after fixing any argument
in Item_func::fix_fields() and Item_cond::fix_fields accordingly.
The convert_constant_item() function now doesn't convert a constant item
if the with_subselect flag set in it.
The select statement that specified a view could be
slightly changed when the view was saved in a frm file.
In particular references to an alias name in the HAVING
clause could be substituted for the expression named by
this alias.
This could result in an error message for a query of
the form SELECT * FROM <view>. Yet no such message
appeared when executing the query specifying the view.
itself when executing queries referring to a view with GROUP BY
an expression containing non-constant interval.
It happened because Item_date_add_interval::eq neglected the
fact that the method can be applied to an expression of the form
date(col) + interval time_to_sec(col) second
at the time when col could not be evaluated yet.
An attempt to evaluate time_to_sec(col) in this method resulted
in a crash.
When a view statement is compiled on CREATE VIEW time, most of the
optimizations should not be done. Finding the right optimization
for a subquery is one of them.
Unfortunately the optimizer is resolving the column references of
the left expression of IN subqueries in the process of deciding
witch optimization to use (if needed). So there should be a
special case in Item_in_subselect::fix_fields() : check the
validity of the left expression of IN subqueries in CREATE VIEW
mode and then proceed as normal.
Error was emitted when one tried to select information from view which used
merge algorithm and which also had CONVERT_TZ() function in its select list.
This bug was caused by wrong assumption that global table list for view
which is handled using merge algorithm begins from tables belonging to
the main select of this view. Nowadays the above assumption is not true only
when one uses convert_tz() function in view's select list, but in future
other cases may be added (for example we may support merging of views
with subqueries in select list one day). Relying on this false assumption
led to the usage of wrong table list for field lookups and therefor errors.
With this fix we explicitly use pointer to the beginning of main select's
table list.
The function agg_cmp_type in item_cmpfunc.cc neglected the fact that
the first argument in a BETWEEN/IN predicate could be a field of a view.
As a result in the case when the retrieved table was hidden by a view
over it and the arguments in the BETWEEN/IN predicates are of
the date/time type the function did not perform conversion of
the constant arguments to the same format as the first field argument.
If formats of the arguments differed it caused wrong a evaluation of
the predicates.
The code in opt_sum_query that prevented the COUNT/MIN/MAX
optimization from being applied to outer joins was not adjusted
after introducing nested joins. As a result if an outer join
contained a reference to a view as an inner table the code of
opt_sum_query missed the presence of an on expressions and
erroneously applied the mentioned optimization.
When the Item_cond::fix_fields() function reduces cond tree, it in loop
scans it's own list and when it founds Item_cond with same function (AND
or OR) it does next things: 1) replaces that item with item's list. 2)
empties item's list. Due to this operation is done twice - for update and
for view, at the update phase cond's list of lower view is already empty.
Empty list returns ref to itself, thus making endless loop by replacing
list with itself, emptying, replacing again and so on. This results in
server hung up.
To the Item_cond::fix_fields() function added check that ensures that
list being replaced with isn't empty.
When an ambiguous field name is used in a group by clause a warning is issued
in the find_order_in_list function by a call to push_warning_printf.
An expression that was not always valid was passed to this call as the field
name parameter.
- Fixed tests
- Optimized new code
- Fixed some unlikely core dumps
- Better bug fixes for:
- #14397 - OPTIMIZE TABLE with an open HANDLER causes a crash
- #14850 (ERROR 1062 when a quering a view using a Group By on a column that can be null
impossible view security".
We should not expose names of tables which are explicitly or implicitly (via
routine or trigger) used by view even if we find that they are missing.
So during building of list of prelocked tables for statement we track which
routines (and therefore tables for these routines) are used from views. We
mark elements of LEX::routines set which correspond to routines used in views
by setting Sroutine_hash_entry::belong_to_view member to point to TABLE_LIST
object for topmost view which uses routine. We propagate this mark to all
routines which are used by this routine and which we add to this set. We also
mark tables used by such routine which we add to the list of tables for
prelocking as belonging to this view.
