func_view.inc

这个文件是windows mysql源码

###################################################
#                                                 #
#  Functions within VIEWs                         #
#                                                 #
###################################################
# Created 2005-09-14 mleich

#
# 0.  Some notes about this test:
# #################################################################
#
# 0.1   This test is unfinished and incomplete, but already useful.
# -----------------------------------------------------------------
# 0.1.1 There will be architectural changes in future.
#       The long sequences with
#           let $col_type= <column to use>;
#           --source suite/funcs_1/views/<file containing the
#                                         select with function>
#       per every column type do not look very smart.
#
#       Ugly combinations of functions and data types must be also checked,
#       because an accidental typo like assigning a string column to an
#       numeric parameter could happen and should not result in a server crash.
#
#       Maybe it is better to change the architecture of this test in such
#       a way:
#       1. A generator script (this one or written in Perl or SP language)
#          generates an prototype of the the final testscript.
#       2. Some manual adjustments because of open bugs (depending on
#          storage engine or function) might be needed (I hope not :)
#       3. The final testscript is pushed to the other regression testscripts.
#       Advantage:    The analysis of bugs, extension and maintenance of this
#                     test will be much easier.
#       Disadvantage: Much redundant code within the final testscript,
#                     but the maintenance of the redundant code will be done
#                     by the script generator.
#
# 0.1.2 The behaviour of SELECTs on VIEWs could be affected by the SQL mode
#       which was valid during VIEW creation time. This means some variations
#       of the SQL mode are needed.
# 0.1.3 There are much more functions to be tested.
# 0.1.4 The result sets of some CAST sub testcases with ugly function parameter
#       column data type combinations must be discussed.
#
#
# 0.2   How to valuate the test results:
# ---------------------------------------------------------------------------
#       Due to the extreme "greedy bug hunting" architecture (combinatorics
#       + heavy use of sourced scripts) of the following tests, there will be
#       - no abort of the test execution, when one statements gets an return
#         code != 0 (The sub testcases are independend.)
#         But statements, which do not make sense like SELECT on non existent
#         VIEW will be omitted. This decreases the amount of useless output.
#       - a file with expected results, which might contain incorrect server
#         responses
#         There are open bugs and I cannot omit statements which reveal these
#         bugs.
#         But there will be a special messages within the protocol files.
#         Example:
#            "Attention: CAST --> SIGNED INTEGER
#            The file with expected results suffers from Bug 5913";
#            means, the file with expected results contains result sets which
#            are known to be wrong.
#            "Attention: The last <whatever> failed"
#            means, a statement which should be successful (bugfree MySQL)
#            failed.
#
#       "Passed" : The behaviour of your MySQL version does not differ from the
#                  version used to generate the files with expected results.
#                  Known bugs affecting these tests could be retrieved by
#                  grep "Attention" r/<testcase>.result .
#
#       "Failed" : The behaviour of your MySQL version differs from the version
#                  used to generate the files with expected results.
#                  These differences could be result of bug fixes or new bugs.
#                  Please compare r/<testcase>.reject and r/<testcase>.result .
#
#      The test will abort if one of the basic preparation statement fails
#      (except ALTER TABLE ADD ...).
#
#
# 0.3   How to debug sub testcases with "unexpected" results:
# ---------------------------------------------------------------------------
#       1. Please execute this test and copy the "reject" file to a save place.
#          Search within the "reject" file for the sub testcase (the SELECT)
#          with the suspicious result set or server response.
#          Now all t1_values records are preloaded.
#       2. Start the server without the initial cleanup of databases etc.
#          This preserves the content of the table t1_values, which
#          might be needed for replaying the situation.
#          Example:
#            ./mysql-test-run.pl   --socket=var/tmp/master.sock --start-dirty
#       3. Issue the statements needed by using "mysql" or "mysqltest".
#
#       Maybe an internal routine of this test fails. Please ask me (mleich) or
#       enable the logging of auxiliary queries and try to analyze the
#       problem.
#
#
# 0.4   How to extend the number of functions to be checked:
# ---------------------------------------------------------------------------
#       Please jump to the paragraphs of the basic preparations
#       1. Extend t1_values with the columns you need
#       2. Insert some predefinded rows
#       3. Add the SELECTs with function which should be used within VIEWs
#          and
#          records which should be used dedicated to the SELECT above
#
#
# 0.5  How to alter the internal routines of this test:
# ---------------------------------------------------------------------------
#      Please try to achieve a state where the protocol
#      - contains ALL statements, which are needed to replay a problem within
#        the field of functions within VIEWs
#      - does not contain too much auxiliary statements, which are not needed
#        to replay a problem (--> "--disable_query_log")
#      Example:
#        Needed for replay:
#        - DROP/CREATE TABLE t1_values
#        - INSERT of records into t1_values
#        - DROP/CREATE/SELECT/SHOW VIEW v1
#        - SELECT direct on base table
#        Not needed for replay:
#        - SET @<uservariable> = <value>
#        - DROP/CREATE/INSERT/SELECT TABLE t1_selects, t1_modes
#
#
# 0.6  A trick for checking results
# ---------------------------------------------------------------------------
#   Standard setting for common execution of this test:
    let $simple_select_result= 1;
    let $view_select_result=   1;
#      The implementation of some additional function tests may lead to
#      masses of result sets, which have to be checked. The result sets of
#      the simple selects on the base table must equal the result sets of the
#      queries on the VIEWs. This step could be made more comfortable by
#      1. Edit this file to
#              let $simple_select_result= 1;
#              let $view_select_result=   0;
#         Please execute this test.
#         The script will omit CREATE/DROP/SHOW/SELECT on VIEW.
#         The "reject" file contains only the simple select result sets.
#      2. Edit this file to
#              let $simple_select_result= 0;
#              let $view_select_result=   1;
#         Please execute this test.
#         The script will work with the VIEWs, but omit the simple selects.
#         The "reject" file contains the view select result sets.
#      3. Compare the "reject" files of 1. and 2. within a graphical diff tool.
#
#

--disable_warnings
DROP TABLE IF EXISTS t1_selects, t1_modes, t1_values;
DROP VIEW  IF EXISTS v1;
--enable_warnings

--disable_query_log
# Storage for the SELECTs to be used for the VIEW definition
CREATE TABLE t1_selects
(
   id BIGINT AUTO_INCREMENT,
   my_select VARCHAR(200) NOT NULL,
   disable_result ENUM('Yes','No') NOT NULL default 'No',
   PRIMARY KEY(id),
   UNIQUE (my_select)
);

# MODES to be checked
CREATE TABLE t1_modes
(
   id BIGINT AUTO_INCREMENT,
   my_mode VARCHAR(200) NOT NULL,
   PRIMARY KEY(id),
   UNIQUE (my_mode)
);
--enable_query_log

# The table to be used in the FROM parts of the SELECTs
--replace_result $type <engine_to_be_tested>
eval CREATE TABLE t1_values
(
   id BIGINT AUTO_INCREMENT,
   select_id BIGINT,
   PRIMARY KEY(id)
) ENGINE = $type;

##### BEGIN      Basic preparations      #######################################
#
# 1. Extend t1_values with the columns you need
#    - the column name must show the data type
#    - do not add NOT NULL columns
#    - do not worry if the intended column data type is not
#      available for some storage engines
#    Please do not forget to assign values for the new columns (paragraph 2.).
--disable_abort_on_error
ALTER TABLE t1_values ADD my_char_30        CHAR(30);
ALTER TABLE t1_values ADD my_varchar_1000   VARCHAR(1000);
ALTER TABLE t1_values ADD my_binary_30      BINARY(30);
ALTER TABLE t1_values ADD my_varbinary_1000 VARBINARY(1000);
ALTER TABLE t1_values ADD my_datetime       DATETIME;
ALTER TABLE t1_values ADD my_date           DATE;
ALTER TABLE t1_values ADD ts_dummy          TIMESTAMP;
ALTER TABLE t1_values ADD my_timestamp      TIMESTAMP;
ALTER TABLE t1_values ADD my_time           TIME;
ALTER TABLE t1_values ADD my_year           YEAR;
ALTER TABLE t1_values ADD my_bigint         BIGINT;
ALTER TABLE t1_values ADD my_double         DOUBLE;
ALTER TABLE t1_values ADD my_decimal        DECIMAL(64,30);
--enable_abort_on_error

#-------------------------------------------------------------------------------

#
# 2.  Insert some predefinded rows
#     Predefined rows
#     - t1_values.select_id IS NULL
#     - will be selected by every SELECT with function to be tested
#     - have to be inserted when sql_mode = 'traditional' is valid, because
#       we do not want to start with "illegal/unexpected/..." values.
#       Such experiments should be done in other testcases.
#     Please be careful
#     - modifying column values of predefined rows they might change many
#       result sets
#     - additional predefined rows should be really useful for the majority of
#       all sub testcases, since they blow up all result sets.
SET sql_mode = 'traditional';
#
# 2.1 record -- everything to NULL
INSERT INTO t1_values SET id = 0;
#
# 2.2 record -- everything to "minimum"
#     numbers, date/time types -> minimum of range
#     strings, blobs, binaries -> ''
#     FIXME enum, set ??
INSERT INTO t1_values SET
       my_char_30 = '',
       my_varchar_1000 = '',
       my_binary_30 = '',
       my_varbinary_1000 = '',
       my_datetime = '0001-01-01 00:00:00',
       my_date = '0001-01-01',
       my_timestamp = '1970-01-01 03:00:01',
       my_time = '-838:59:59',
       my_year = '1901',
       my_bigint = -9223372036854775808,
       my_decimal = -9999999999999999999999999999999999.999999999999999999999999999999 ,
       my_double = -1.7976931348623E+308;
# shortened due to bug#32285
#       my_double = -1.7976931348623157E+308;
#
# 2.3 record -- everything to "maximum"
#     numbers, date/time types -> maximum of range
#     strings, blobs, binaries -> '<- full length of used data type>'
#     FIXME enum, set ??
INSERT INTO t1_values SET
       my_char_30 = '<--------30 characters------->',
       my_varchar_1000 = CONCAT('<---------1000 characters',
                                RPAD('',965,'-'),'--------->'),
       my_binary_30 = '<--------30 characters------->',
       my_varbinary_1000 = CONCAT('<---------1000 characters',
                                RPAD('',965,'-'),'--------->'),
       my_datetime = '9999-12-31 23:59:59',
       my_date = '9999-12-31',
       my_timestamp = '2038-01-01 02:59:59',
       my_time = '838:59:59',
       my_year = 2155,
       my_bigint = 9223372036854775807,
       my_decimal = +9999999999999999999999999999999999.999999999999999999999999999999 ,
       my_double = 1.7976931348623E+308;
# shortened due to bug#32285
#       my_double = -1.7976931348623157E+308;
#
# 2.4 record -- everything to "magic" value if available or
#               other interesting value
#     numbers   -> 0
#     strings, blobs, binaries -> not full length of used data type, "exotic"
#                                 characters and preceeding and trailing spaces
#     FIXME enum, set ??
INSERT INTO t1_values SET
       my_char_30 = ' ---äÖüß@µ*$-- ',
       my_varchar_1000 = ' ---äÖüß@µ*$-- ',
       my_binary_30 = ' ---äÖüß@µ*$-- ',
       my_varbinary_1000 = ' ---äÖüß@µ*$-- ',
       my_datetime = '2004-02-29 23:59:59',
       my_date = '2004-02-29',
       my_timestamp = '2004-02-29 23:59:59',
       my_time = '13:00:00',
       my_year = 2000,
       my_bigint = 0,  	
       my_decimal = 0.0,
       my_double = 0;
#
# 2.5 record -- everything to "harmless" value if available
#     numbers -> -1 (logical)
#     strings, blobs, binaries -> '-1' useful for numeric functions
#     FIXME enum, set ??
INSERT INTO t1_values SET
       my_char_30 = '-1',
       my_varchar_1000 = '-1',
       my_binary_30 = '-1',
       my_varbinary_1000 = '-1',
       my_datetime = '2005-06-28 10:00:00',
       my_date = '2005-06-28',
       my_timestamp = '2005-06-28 10:00:00',
       my_time = '10:00:00',
       my_year = 2005,
       my_bigint = -1,
       my_decimal = -1.000000000000000000000000000000,
       my_double = -0.1E+1;

#-------------------------------------------------------------------------------

#
# 3.  Add the SELECTs with function which should be used within VIEWs
#     and
#     records which should be used dedicated to the SELECT above
#     - Please avoid WHERE clauses
#     - Include the PRIMARY KEY ("id") of the base table t1_values into the
#       select column list
#     - Include the base table column used as function parameter into the
#       select column list, because it is much easier to check the results
#     - Do not forget to escape single quotes
#       Example:
#        SET @my_select = 'SELECT sqrt(my_bigint), my_bigint, id FROM t1_values'
#        SET @my_select = 'SELECT CONCAT(\'A\',my_char_30), id FROM t1_values';
#     - Statements, which reveal open crashing bugs MUST be disabled.
#     - Result sets must not contain data, which might differ between boxes
#       executing this test.
#       Example: current time, absolute path to some files ...
#     - Please derive the functions to be checked from the MySQL manual
#       and use the same order. This means copy the the function names as
#       comment into this test and start to implement a testcase for your
#       most preferred function.
#       This method avoids that we forget a function and gives a better
#       overview.
#
#     If you have the time to check the result sets do the insert of the
#     SELECT with function via: