WL#4904: Introduce Value Registers in Item class hierarchy

Introduction
============
When parsing SQL statements, an Item object tree is created for each
expression. Each node of the tree represents a constant, a field, an
operator, a function call, or similar. Today, four basic types are
supported for results of expression arithmetics (longlong, double,
my_decimal, and String). Each Item subclass will need to handle
arguments (subtrees) of all supported types, and be able to deliver
result in all supported types. Currently, each Item subclass need to
support four methods val_int(), val_real(), val_decimal(), and
val_str(). If a new type (e.g., DATETIME) were to be supported in
Item arithmetics, a new method would have to be added to each class
(either directly or through inheritance.)
Goals
=====
The purpose of this worklog is to introduce a Value object that can
represent a value of any type used in SQL expressions. This task has the
following primary goals:
1) Have a centralized API to access and convert a single value (data)
of SQL expressions.
Today, logic for converting between types are contained in val_xxx
methods of Item class hierarchy. In addition to making it
difficult to add new types, it also lead to a lot of
inconsistencies where conversion between types varies depending on
context.
2) Have a centralized API for metadata operations.
Today, when we evaluate properties of the expression, rules to
calculate metadata are scattered across the Item class hierarchy.
The goal is to move all functionality responsible for evaluation of
result metadata to a central location, separated from the Item
hierarchy.
3) Simplify addition of new expression result types to the Item
hierarchy.
The goal of this task is to have a single place to extend when
adding support for a new expression result type, by separating this
functionality from the Item class hierarchy.
In addition to the above primary goals, there are some secondary
quality goals:
4) No introduction of unnecessary copying and conversions of data in
the execution layer.
5) All changes to functional behavior must documented.
This task is also relevant for a few long-term MySQL goals that are
beyond the scope of this work. However, we should keep in mind that
our design should not make these goals more difficult to achieve:
6) Avoiding unnecessary copying of data when passing values to/from
the storage engine.
7) Make the execution tree reusable from different connections.
Field Class Hierarchy
=====================
The goals discussed for the Item class hierarchy above, will also be
applied for the Field class hierarchy, which has similar issues with
respect to duplication of code for conversion between types. Also,
since type metadata for expressions are often derived from field
metadata, it makes sense to also let a centralized API for metadata
operations handle the Field hierarchy.
Value Registers
===============
WL#4760 describes a design based on immutable Value objects that where
returned by value (e.g., "Value Item::value()"). In order to
reduce the cost copying a Value object, it only contained references
to larger values like string values. This created issues with respect
to ownership of data that could not be easily solved (see WL#4760 for
more details).
An alternative to pass around immutable values, is to pass around
a reference to a storage location for a piece of data, i.e. similar to
the concept of a computer register. For example, Item could in order
to evaluate an expression provide a method "Item::eval(Register*)",
and store the result of the evaluation in the register provided by the
caller. This approach has some advantages:
- It is clear that the caller has ownership to the data.
- In most cases, the caller will know in what form it wants the
result. Through metadata associated with the passed in register,
the caller can specify the desired type etc. for the result. This
may avoid materializing intermediate results in other forms during
the evaluation.
- Registers can be reused for different values. Hence, it does not
require allocation of a new object for each value that is produced.
- The caller may pre-allocate buffers to be used for the result and
avoid dynamic allocation of memory during the evaluation.
This task will explore the use of Value registers.

Requirements
============
A walk-through of some examples of SQL statements revealed the
following set of requirements.
(Ref.
https://intranet.mysql.com/secure/mailarchive/mail.php?folder=4&mail=29772) It
should be possible to:
Req 1) Construct a value for a parser constant - avoiding extra
copying, if possible. E.g., "SELECT "long text";
Req 2) Store an instance of class Value in the protocol, avoiding
extra copying and unnecessary switch (type), if possible.
(Under "protocol" here we meant the client-server protocol, and
class Protocol in particular.)
Req 3) Get a value object from the storage engine, and later on store
it in the protocol.
Req 4) Evaluate the result metadata and store it in the protocol (send
it to the client) *before evaluating a value*.
Req 5) Know the resulting type of the expression before evaluating the
expression. The logic that is responsible for that operation
needs to be moved to a central location.
Req 6) Have a central location for type data conversion
functionality. This functionality should be accessed through an
API.
Req 7) Have a central location for the implementation of
operations. Since we would like to simplify addition of
new expression result types, implementation of e.g.
the operation "+" must be moved to a central location.
(Other similar operations are: +, -, /, *, mod, div, <, >, <=,
>=, <>, |, ||, &, &&, ^, etc.)
Req 8) To change expression result metadata between executions of a
statement. Expression result metadata is constant during a
single execution, but may change between executions since
parameter types as in "SELECT ?, ?;" may change from execution
to execution.
Note: This requirement affects where we can store expression
metadata and where we allocate memory for it.
We would like to avoid storing result metadata in the
Item objects, since one of our (non-primary) goals is to
make the execution tree reusable from different
connections, and Sqltype_metadata will be specific to
each connection.
We would also like to avoid storing metadata in the Value
object, since we may want to create and manipulate with
instances of metadata objects prior to evaluation of the
expression, i.e., perhaps, before we have instances of
class Value.
Req 9) Convert a Value to int, char, string, etc.
There are times when we will need to convert a value into a
builtin C++-type:
1) We need to convert the result of an expression to
TRUE/FALSE in WHERE and HAVING clauses. NULL is false.
2) We need to convert the result an expression to unsigned
longlong in LIMIT clause.
3) We need to be able to store the result of an expression in
the Protocol, therefore Value needs to publish a
send(Protocol *) method, or an analogue.
4) Today, we use val_str(), val_int() and other val_* methods
of class Field currently in simplistic engines, such as
CSV or ARCHIVE, to retrieve the data from table->record[].
SUBTASKS
========
1) Centralized API for metadata operations (WL#5081)
(Requirements 4 and 5 above)
2) Value register implementation (WL#5082)
(Req. 1, 6, and 9)
3) Introduce Value registers in Field classes (WL# TBD)
(Req. 3)
4) Introduce Value registers in Item classes (WL# TBD)
(Req. 8)
5) Introduce Value registers in Protocol (WL# TBD)
(Req. 2)
6) Centralized API for operations on Values (WL# TBD)
(Req. 7)
More subtasks to come ...