Added basic per-thread time zone functionality (based on public
domain elsie-code). Now user can select current time zone
(from the list of time zones described in system tables).
All NOW-like functions honor this time zone, values of TIMESTAMP
type are interpreted as values in this time zone, so now
our TIMESTAMP type behaves similar to Oracle's TIMESTAMP WITH
LOCAL TIME ZONE (or proper PostgresSQL type).
WL#1266 "CONVERT_TZ() - basic time with time zone conversion
function".
Fixed problems described in Bug #2336 (Different number of warnings
when inserting bad datetime as string or as number). This required
reworking of datetime realted warning hadling (they now generated
at Field object level not in conversion functions).
Optimization: Now Field class descendants use table->in_use member
instead of current_thd macro.
- New solution after discussions with Sergei, no handler specific code or error messages should be in sql layer.
next_result, only check for error if check is -1
Improved index_read
fixed IN subselect with basic constant left expression
SQLCOM_CREATE_TABLE, SQLCOM_UPDATE_MULTI, SQLCOM_REPLACE_SELECT, SQLCOM_INSERT_SELECT, QLCOM_DELETE_MULTI fixed to be compatible with PS (BUG#3398, BUG#3406)
fixed multiupdate privelege check (BUG#3408)
fixed multiupdate tables check (BUG#3411)
unchecked commands now is rejected by PS protocol to avoid serever crash
fixed cleunup procedure to be compatible sith DO/SET (BUG#3393)
Final version of patch.
Adds support for specifying of DEFAULT NOW() and/or ON UPDATE NOW()
clauses for TIMESTAMP field definition.
Current implementation allows only one such field per table and
uses several unireg types for storing info about this properties of
field. It should be replaced with better implementation when new
.frm format is introduced.
Cleaned up embedded library access and query cache handling
Changed min stack size to 128K (to allow longer MyISAM keys)
Fixed wrong priority for XOR (should be less than NEG to get -1^1 to work)
more general message when slave can't start because of incorrect
replication information, the previous one was sometimes a misleading
indication (i.e. sometimes the problem had nothing to do with
system permissions).
The perfect fix would be to report the exact error to the client
(instead of pointing the client to the error log); this is a bit
of work so it's more a development task:
WL#1088 "Move all hardcoded messages of replication to share/errmsg.txt".
I was not able to modify the errmsg.txt in these sql/ subdirectories:
danish
dutch
german
italian
portuguese
russian
spanish
swedish
ukrainian
