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.
This bug is just one facet of stored routines not being able to
detect changes in meta-data (WL#4179). This particular problem
can be triggered within a single session due to the improper
management of the pre-locking list if the view is expanded after
the pre-locking list is calculated.
Since the overall solution for the meta-data detection issue is
planned for a later release, for now a workaround is used to
fix this particular aspect that only involves a single session.
The workaround is to flush the thread-local stored routine cache
every time a view is created or modified, causing locally cached
routines to be re-evaluated upon invocation.
check_key_in_view() had one code branch which returned with "return TRUE"
rather than "DBUG_RETURN(TRUE)". Only affected debug builds.
No test case added.
Implemented the server infrastructure for the fix:
1. Added a function LEX_STRING *thd_query_string(THD) to return
a LEX_STRING structure instead of char *.
This is the function that must be called in innodb instead of
thd_query()
2. Did some encapsulation in THD : aggregated thd_query and
thd_query_length into a LEX_STRING and made accessor and mutator
methods for easy code updating.
3. Updated the server code to use the new methods where applicable.
with gcc 4.3.2
This patch fixes a number of GCC warnings about variables used
before initialized. A new macro UNINIT_VAR() is introduced for
use in the variable declaration, and LINT_INIT() usage will be
gradually deprecated. (A workaround is used for g++, pending a
patch for a g++ bug.)
GCC warnings for unused results (attribute warn_unused_result)
for a number of system calls (present at least in later
Ubuntus, where the usual void cast trick doesn't work) are
also fixed.
The problem: described in the bug report.
The fix:
--increase buffers where it's necessary
(buffers which are used in stxnmov)
--decrease buffer lengths which are used
with gcc 4.3.2
Compiling MySQL with gcc 4.3.2 and later produces a number of
warnings, many of which are new with the recent compiler
versions.
This bug will be resolved in more than one patch to limit the
size of changesets. This is the second patch, fixing more
of the warnings.
Make the caller of Query_log_event, Execute_load_log_event
constructors and THD::binlog_query to provide the error code
instead of having the constructors to figure out the error code.
mysql_rename_view can not rename view if database is not the same.
The fix is to add new argument 'new_db' to mysql_rename_view() and
allow rename with different databases
(only for ALTER DATABASE ... UPGRADE DATA DIRECTORY NAME).
When the thread executing a DDL was killed after finished its
execution but before writing the binlog event, the error code in
the binlog event could be set wrongly to ER_SERVER_SHUTDOWN or
ER_QUERY_INTERRUPTED.
This patch fixed the problem by ignoring the kill status when
constructing the event for DDL statements.
This patch also included the following changes in order to
provide the test case.
1) modified mysqltest to support variable for connection command
2) modified mysql-test-run.pl, add new variable MYSQL_SLAVE to
run mysql client against the slave mysqld.
- Remove bothersome warning messages. This change focuses on the warnings
that are covered by the ignore file: support-files/compiler_warnings.supp.
- Strings are guaranteed to be max uint in length
- Remove bothersome warning messages. This change focuses on the warnings
that are covered by the ignore file: support-files/compiler_warnings.supp.
- Strings are guaranteed to be max uint in length
TABLE_LIST doesn't free Strings in its string lists
(TABLE_LIST::use_index and TABLE_liST::ignore_index), so
calling c_ptr_safe() on that Strings leads to memleaks.
OTOH "safe" c_ptr_safe() is not necessary there and we can
replace it with c_ptr().
an error
Even after the fix for bug 28701 visible behaviors of
SELECT FROM a view and SELECT FROM a regular table are
little bit different:
1. "SELECT FROM regular table USE/FORCE/IGNORE(non
existent index)" fails with a "ERROR 1176 (HY000):
Key '...' doesn't exist in table '...'"
2. "SELECT FROM view USING/FORCE/IGNORE(any index)" fails
with a "ERROR 1221 (HY000): Incorrect usage of
USE/IGNORE INDEX and VIEW". OTOH "SHOW INDEX FROM
view" always returns empty result set, so from the point
of same behaviour view we trying to use/ignore non
existent index.
To harmonize the behaviour of USE/FORCE/IGNORE(index)
clauses in SELECT from a view and from a regular table the
"ERROR 1221 (HY000): Incorrect usage of USE/IGNORE INDEX
and VIEW" message has been replaced with the "ERROR 1176
(HY000): Key '...' doesn't exist in table '...'" message
like for tables and non existent keys.
missing after downgrade
Obsolete arc/ directory and view .frm file backup support
has been removed by the patch for bug 17823. However, that
bugfix caused a problem with "live downgrades" of the
server: if we rename some view 4 times under 5.1.29/5.0.72
and then try to rename it under 5.1.28/5.0.70 on the same
database, the server fails with a error:
query 'RENAME TABLE ... TO ...' failed: 6: Error on
delete of '....frm-0001' (Errcode: 2)
Also .frm file of that view may be lost (renamed to .frm~).
The server failed because it tried to rename latest 3
backup .frm files renaming the view: the server used an
integer value of the "revision" field of .frm file to
extract those file names. After the fix for bug 17823 those
files were not created/maintained any more, however the
"revision" field was incremented as usual. So, the server
failed renaming non existent files.
This fix solves the problem by removing the support for
"revision" .frm file field:
1. New server silently ignores existent "revision" fields
in old .frm files and never write it down;
2. Old server assumes, that missing "revision" field in new
.frm files means default value of 0.
3. Accordingly to the fix for bug 17823 the new server
drops arc/ directory on alter/rename view, so after
"live downgrade" old server begins maintenance of the
arc/ directory from scratch without conflicts with .frm
files.
A string buffers which were included in the 'view' data structure
were allocated on the stack, causing an invalid pointer when used
after the function returned.
The fix: use copy of values for view->md5 & view->queries
Server created "arc" directories inside database directories and
maintained there useless copies of .frm files.
Creation and renaming procedures of those copies as well as
creation of "arc" directories has been discontinued.
Removal procedure has been kept untouched to be able to
cleanup existent database directories by the DROP DATABASE
query. Also view renaming procedure has been updated to remove
these directories.
build)
The crash was caused by freeing the internal parser stack during the parser
execution.
This occured only for complex stored procedures, after reallocating the parser
stack using my_yyoverflow(), with the following C call stack:
- MYSQLparse()
- any rule calling sp_head::restore_lex()
- lex_end()
- x_free(lex->yacc_yyss), xfree(lex->yacc_yyvs)
The root cause is the implementation of stored procedures, which breaks the
assumption from 4.1 that there is only one LEX structure per parser call.
The solution is to separate the LEX structure into:
- attributes that represent a statement (the current LEX structure),
- attributes that relate to the syntax parser itself (Yacc_state),
so that parsing multiple statements in stored programs can create multiple
LEX structures while not changing the unique Yacc_state.
Now, Yacc_state and the existing Lex_input_stream are aggregated into
Parser_state, a structure that represent the complete state of the (Lexical +
Syntax) parser.
Problem was that mysql_create_view did not remove all comments characters
when writing to binlog, resulting in parse error of stmt on slave side.
Solution was to use the recreated select clause
and add a generated CHECK OPTION clause if needed.
between 5.0 and 5.1.
The problem was that in the patch for Bug#11986 it was decided
to store original query in UTF8 encoding for the INFORMATION_SCHEMA.
This approach however turned out to be quite difficult to implement
properly. The main problem is to preserve the same IS-output after
dump/restore.
So, the fix is to rollback to the previous functionality, but also
to fix it to support multi-character-set-queries properly. The idea
is to generate INFORMATION_SCHEMA-query from the item-tree after
parsing view declaration. The IS-query should:
- be completely in UTF8;
- not contain character set introducers.
For more information, see WL4052.
The problem is that CREATE VIEW statements inside prepared statements
weren't being expanded during the prepare phase, which leads to objects
not being allocated in the appropriate memory arenas.
The solution is to perform the validation of CREATE VIEW statements
during the prepare phase of a prepared statement. The validation
during the prepare phase assures that transformations of the parsed
tree will use the permanent arena of the prepared statement.
a table name.
The problem was that fill_defined_view_parts() did not return
an error if a table is going to be altered. That happened if
the table was already in the table cache. In that case,
open_table() returned non-NULL value (valid TABLE-instance from
the cache).
The fix is to ensure that an error is thrown even if the table
is in the cache.
(This is a backport of the original patch for 5.1)
The problem is that when a stored procedure is being parsed for
the first execution, the body is copied to a temporary buffer
which is disregarded sometime after the statement is parsed.
And during this parsing phase, the rule for CREATE VIEW was
holding a reference to the string being parsed for use during
the execution of the CREATE VIEW statement, leading to invalid
memory access later.
The solution is to allocate and copy the SELECT of a CREATE
VIEW statement using the thread memory root, which is set to
the permanent arena of the stored procedure.
a table name.
The problem was that fill_defined_view_parts() did not return
an error if a table is going to be altered. That happened if
the table was already in the table cache. In that case,
open_table() returned non-NULL value (valid TABLE-instance from
the cache).
The fix is to ensure that an error is thrown even if the table
is in the cache.
