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.
Bug #18361: Triggers on mysql.user table cause server crash
Because they do not work, we do not allow creating triggers on tables
within the 'mysql' schema.
(They may be made to work and re-enabled at some later date, but not
in 5.0 or 5.1.)
It fact, filenames are truncated in normal server as well, just we
get bigger filenames in embedded server tests, but that can potentially
get some problems in both cases.
I modified file-related error messages to allow longer filenames
from within triggers
Add support for passing NEW.x as INOUT and OUT parameters to stored
procedures. Passing NEW.x as INOUT parameter requires SELECT and
UPDATE privileges on that column, and passing it as OUT parameter
requires only UPDATE privilege.
The SQL standard doesn't allow to use in HAVING clause fields that are not
present in GROUP BY clause and not under any aggregate function in the HAVING
clause. However, mysql allows using such fields. This extension assume that
the non-grouping fields will have the same group-wise values. Otherwise, the
result will be unpredictable. This extension allowed in strict
MODE_ONLY_FULL_GROUP_BY sql mode results in misunderstanding of HAVING
capabilities.
The new error message ER_NON_GROUPING_FIELD_USED message is added. It says
"non-grouping field '%-.64s' is used in %-.64s clause". This message is
supposed to be used for reporting errors when some field is not found in the
GROUP BY clause but have to be present there. Use cases for this message are
this bug and when a field is present in a SELECT item list not under any
aggregate function and there is GROUP BY clause present which doesn't mention
that field. It renders the ER_WRONG_FIELD_WITH_GROUP error message obsolete as
being more descriptive.
The resolve_ref_in_select_and_group() function now reports the
ER_NON_GROUPING_FIELD_FOUND error if the strict mode is set and the field for
HAVING clause is found in the SELECT item list only.
Check if AGGREGATE was given with a stored (non-UDF) function, and return
error in that case.
Also made udf_example/udf_test work again, by adding a missing *_init()
function. (_init() functions required unless --allow_suspicious_udfs is
given to the server, since March 2005 - it seems udf_example wasn't updated
at the time.)
latin5.xml:
- Fixing order thee Turkish letters to conform Turkish rules.
- All non-Turkish accented letters are mappend
to their non-accented counterparts.
Post-review version. Some minor review fixes, but also changed the way
some errors are handled: Don't return specific parse errors; instead
always use the more general "table corrupt" error (amended accordingly).
Bad examples of usage of a string with its length fixed.
The incorrect length in the trigger file configuration descriptor
fixed (BUG#14090).
A hook for unknown keys added to the parser to support old .TRG files.
Indeed now that stored procedures CALL is not binlogged, but instead the invoked substatements are,
the restrictions applied by log-bin-trust-routine-creators=0 are superfluous for procedures.
They still need to apply to functions where function calls are written to the binlog (for example as "DO myfunc(3)").
We rename the variable to log-bin-trust-function-creators but allow the old name until some future version (and issue a warning if old name is used).
Fixing latin1 to cp1252, according to
recent changes in ctype-latin1.c.
Index.xml:
Marking latin1_swedish_ci as "compiled"
to avoid its generating into ctype-extra.c.
ctype-extra.c:
Bug#12076 --with-extra-charsets has no effect
All supported dnamic charsets were generated
from sql/share/charsets/*.xml under #ifdefs.
Compiling is to be activated from "configure"
by adding --with-extra-charsets.
I'm not including auto-recreating of ctype-extra.c
into build process for ease purposes.
