The code for creation of temporal literals, such as:

• TIME'10:20:30'
• {t'10:20:30'}

currently resides in:
1. create_temporal_literal() in item_create.cc
2. Item_string::odbc_temporal_literal_type()
3. Item_string::make_odbc_literal()

and has various switches on MYSQL_TYPE_XXX

This is not friendly to data type plugins.

New data types will support their own literals:

• INET6'0::0'
• {guid 'nnnnnnnn-nnnn-nnnn-nnnn-nnnnnnnnnnnn'}

Under terms of this task we'll move the code to Type_handler by adding the following methods:

static const Type_handler *odbc_literal_type_handler(const LEX_CSTRING *str);

virtual Item_literal *create_literal_item(THD *thd,

                                          const char *str, size_t length,

                                          CHARSET_INFO *cs,

                                          bool send_error) const;

This task is only about moving the code to class Type_handler.

Limitations:

• odbc_literal_type_handler() will still resolve only TIME, DATE and DATETIME literals, as before.

• The code in sql_yacc.yy will still create literals for hard-coded builtin data types TIME, DATE, DATETIME, like this:

  temporal_literal:

  DATE_SYM TEXT_STRING

  {

  if (unlikely(!($$= type_handler_newdate.create_literal_item(thd,

  $2.str, $2.length,

  YYCSCL, true))))

  MYSQL_YYABORT;

  }

The following changes will be done separately, later:

• Extend odbc_literal_type_handler() with a hash for additional data types that want ODBC literals, so a user plugin (such as guid) can register itself in this hash, telling the server that it wants to support ODBC style literals.
• Fix the parser to support pluggable data types.