An error occurred fetching the project authors.
- 27 Oct, 2006 1 commit
-
-
kroki/tomash@moonlight.intranet authored
a updatable view. When there's a VIEW on a base table that have AUTO_INCREMENT column, and this VIEW doesn't provide an access such column, after INSERT to such VIEW LAST_INSERT_ID() did not return the value just generated. This behaviour is intended and correct, because if the VIEW doesn't list some columns then these columns are effectively hidden from the user, and so any side effects of inserting default values to them. However, there was a bug that such statement inserting into a view would reset LAST_INSERT_ID() instead of leaving it unchanged. This patch restores the original value of LAST_INSERT_ID() instead of resetting it to zero.
-
- 23 Oct, 2006 1 commit
-
-
kostja@bodhi.local authored
-
- 17 Oct, 2006 1 commit
-
-
cmiller@zippy.cornsilk.net authored
Remove table engine qualification where it's unnecessary.
-
- 12 Oct, 2006 1 commit
-
-
kroki/tomash@moonlight.intranet authored
should fail to create The problem was that this type of errors was checked during view creation, which doesn't happen when CREATE VIEW is a statement of a created stored routine. The solution is to perform the checks at parse time. The idea of the fix is that the parser checks if a construction just parsed is allowed in current circumstances by testing certain flags, and this flags are reset for VIEWs. The side effect of this change is that if the user already have such bogus routines, it will now get a error when trying to do SHOW CREATE PROCEDURE proc; (and some other) and when trying to execute such routine he will get ERROR 1457 (HY000): Failed to load routine test.p5. The table mysql.proc is missing, corrupt, or contains bad data (internal code -6) However there should be very few such users (if any), and they may (and should) drop these bogus routines.
-
- 10 Oct, 2006 2 commits
-
-
kroki/tomash@moonlight.intranet authored
-
kroki/tomash@moonlight.intranet authored
In a trigger or a function used in a statement it is possible to do SELECT from a table being modified by the statement. However, encapsulation of such SELECT into a view and selecting from a view instead of direct SELECT was not possible. This happened because tables used by views (which in their turn were used from functions/triggers) were not excluded from checks in unique_table() routine as it happens for the rest of tables added to the statement table list for prelocking. With this fix we ignore all such tables in unique_table(), thus providing consistency: inside a trigger or a functions SELECT from a view may be used where plain SELECT is allowed. Modification of the same table from function or trigger is still disallowed. Also, this patch doesn't affect the case where SELECT from the table being modified is done outside of function of trigger, such SELECTs are still disallowed (this limitation and visibility problem when function select from a table being modified are subjects of bug 21326). See also bug 22427.
-
- 29 Sep, 2006 1 commit
-
-
holyfoot/hf@mysql.com/deer.(none) authored
We use the condition from CHECK OPTION twice handling UPDATE command. First we construnct 'update_cond' AND 'option_cond' condition to select records to be updated, then we check the 'option_cond' for the updated row. The problem is that first 'AND' condition is optimized during the 'select' which can break 'option_cond' structure, so it will be unusable for the sectond use - to check the updated row. Possible soultion is either use copy of the condition in the first use or to make optimization less traumatic for the operands. I picked the first one.
-
- 28 Sep, 2006 1 commit
-
-
evgen@moonbone.local authored
On an INSERT into an updatable but non-insertable view an error message was issued stating the view being not updatable. This can lead to a confusion of a user. A new error message is introduced. Is is showed when a user tries to insert into a non-insertable view.
-
- 25 Sep, 2006 1 commit
-
-
igor@rurik.mysql.com authored
Presence of a subquery in the ON expression of a join should not block merging the view that contains this join. Before this patch the such views were converted into into temporary table views.
-
- 18 Sep, 2006 1 commit
-
-
gkodinov@dl145s.mysql.com authored
-
- 14 Sep, 2006 1 commit
-
-
evgen@sunlight.local authored
Added the test case for bug#21677: Wrong result when comparing a DATE and a DATETIME in BETWEEN Corrected a test case after removal of fix for bug#16377 query_cache.result, func_time.test, view.result, view.test, func_time.result: Corrected a test case after removal of fix for bug#16377 type_date.test: Added the test case for bug#21677: Wrong result when comparing a DATE and a DATETIME in BETWEEN Corrected a test case after removal of fix for bug#16377 item_cmpfunc.cc: Removed changes to the Item_func_between::fix_length_and_dec() made in the fix for bug#16377
-
- 06 Sep, 2006 1 commit
-
-
igor@rurik.mysql.com authored
Select_type in the EXPLAIN output for the query SELECT * FROM t1 was 'SIMPLE', while for the query SELECT * FROM v1, where the view v1 was defined as SELECT * FROM t1, the EXPLAIN output contained 'PRIMARY' for the select_type column.
-
- 29 Aug, 2006 2 commits
-
-
kostja@bodhi.local authored
-
kroki/tomash@moonlight.intranet authored
When a view was used inside a trigger or a function, lock type for tables used in a view was always set to READ (thus making the view non-updatable), even if we were trying to update the view. The solution is to set lock type properly.
-
- 24 Aug, 2006 1 commit
-
-
anozdrin/alik@alik. authored
User name (host name) has limit on length. The server code relies on these limits when storing the names. The problem was that sometimes these limits were not checked properly, so that could lead to buffer overflow. The fix is to check length of user/host name in parser and if string is too long, throw an error.
-
- 23 Aug, 2006 2 commits
-
-
evgen@sunlight.local authored
Corrected test case for the bug#21261 sql_parse.cc: Corrected fix for bug#21261
-
anozdrin/alik@alik. authored
User name (host name) has limit on length. The server code relies on these limits when storing the names. The problem was that sometimes these limits were not checked properly, so that could lead to buffer overflow. The fix is to check length of user/host name in parser and if string is too long, throw an error.
-
- 17 Aug, 2006 1 commit
-
-
evgen@moonbone.local authored
Corrected test case result after fix for bug#18165 view.result, view.test: Corrected test case for bug#21261
-
- 15 Aug, 2006 2 commits
-
-
evgen@sunlight.local authored
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.
-
evgen@moonbone.local authored
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.
-
- 02 Aug, 2006 1 commit
-
-
svoj@may.pils.ru authored
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.
-
- 31 Jul, 2006 2 commits
-
-
gkodinov/kgeorge@macbook.gmz authored
made DROP VIEW to continue on error and report an aggregated error at its end. This makes it similar to DROP TABLE.
-
gkodinov/kgeorge@macbook.gmz authored
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.
-
- 25 Jul, 2006 1 commit
-
-
gkodinov/kgeorge@macbook.gmz authored
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.
-
- 20 Jul, 2006 1 commit
-
-
The problem was that when converting a string to an exact number, rounding didn't work, because conversion didn't understand approximate numbers notation. Fix: a new function for string-to-number conversion was implemented, which is aware of approxinate number notation (with decimal point and exponent, e.g. -19.55e-1)
-
- 19 Jul, 2006 1 commit
-
-
igor@olga.mysql.com authored
-
- 14 Jul, 2006 1 commit
-
-
igor@olga.mysql.com authored
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.
-
- 06 Jul, 2006 1 commit
-
-
igor@olga.mysql.com authored
-
- 04 Jul, 2006 1 commit
-
-
gkodinov@mysql.com authored
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.
-
- 27 Jun, 2006 1 commit
-
-
kroki@mysql.com authored
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.
-
- 01 Jun, 2006 1 commit
-
-
igor@rurik.mysql.com authored
-
- 22 May, 2006 1 commit
-
-
igor@rurik.mysql.com authored
-
- 21 May, 2006 1 commit
-
-
igor@rurik.mysql.com authored
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.
-
- 17 May, 2006 2 commits
-
-
evgen@moonbone.local authored
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.
-
igor@rurik.mysql.com authored
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.
-
- 13 May, 2006 1 commit
-
-
igor@rurik.mysql.com authored
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.
-
- 11 May, 2006 1 commit
-
-
gkodinov@mysql.com authored
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.
-
- 26 Apr, 2006 1 commit
-
-
bell@sanja.is.com.ua authored
-
- 22 Apr, 2006 1 commit
-
-
dlenev@mysql.com authored
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.
-
- 13 Apr, 2006 1 commit
-
-
bell@sanja.is.com.ua authored
-