Instead of trying to open time zone tables during calculation of CONVERT_TZ() function
or setting of @@time_zone variable we should open and lock them with the rest of
statement's table (so we should add them to global table list) and after that use such
pre-opened tables for loading info about time zones.
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.
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.
table resolution".
Added members to Item_ident for storing original db, table and field
names since those that set later from Field have shorter life-time
than required by prep. stmt. So we need to restore original names in
Item_ident::cleanup(). Also now using special construnctor for creation
of Item_field from Field object that ensures that table and field name
have big enough life-time.
"Fix" for bug #2050 "10 to 1 performance drop with server 4.1.1"
Clean ups in implementation of caching of field number in table.
Added caching of table in which field is found in find_field_in_tables().
This is to enable table handlers to implement online create/drop index.
It consists of some parts:
- New default handler methods in handler.h
- Split of mysql_alter_table. It decides if only one kind of
alteration is to be done (e.g. only create indexes or only drop
indexes etc.) It then calls the specialized new handler method if
the handler implements it. Otherwise it calls real_alter_table.
- The parser sets flags for each alter operation detected in a
command. These are used by mysql_alter_table for the decision.
- mysql_prepare_table is pulled out of mysql_create_table. This is
also used by mysql_create_index to prepare the key structure array
for the handler. It is also used by mysql_create_index and
mysql_drop_index to prepare a call to mysql_create_frm.
- mysql_create_frm is pulled out of rea_create_table for use by
mysql_create_index and mysql_drop_index after the index is
created/dropped.
Thanks to Antony who supplied most of the changes.
Actually it is not a bug but right behavior observed as pefomance
degradation after we have forced Item_field::fix_fields() to
re-execute each time when we are executing prep stmt.
This patch implements small optimization which heals this bad
behavior. We are caching field position in TABLE::field array in
Item's member and are using this position for speeding up field
lookups in fix_fields() in case of its re-execution.
this is better in this case:
- imagine user1 has created a temp table
- imagine user2 does FLUSH TABLES WITH READ LOCK, then takes a backup,
then RESET MASTER then UNLOCK TABLES, like mysqldump --first-slave
- then in the binlog you will finally have the DROP TEMPORARY TABLE,
but not the CREATE TEMPORARY TABLE, so when you later restore with
mysqlbinlog|mysql, mysql will complain that table does not exist.
Replication was already protected of this (it processes DROP TEMPORARY
TABLE as if there was a IF EXISTS), now I add it directly to the query
for mysqlbinlog|mysql to work.
