The Perl Toolchain Summit needs more sponsors. If your company depends on Perl, please support this very important event.
 / 
SQL-SplitStatement-0.30000
River stage two • 6 direct dependents • 31 total dependents
1 ++
/ SQL::SplitStatement

NAME

SQL::SplitStatement - Split any SQL code into atomic statements

VERSION

version 0.30000

SYNOPSIS

    # Multiple SQL statements in a single string
my $sql_code = <<'SQL';
    CREATE TABLE parent(a, b, c   , d    );
    CREATE TABLE child (x, y, "w;", "z;z");
    /* C-style comment; */
    CREATE TRIGGER "check;delete;parent;" BEFORE DELETE ON parent WHEN
        EXISTS (SELECT 1 FROM child WHERE old.a = x AND old.b = y)
    BEGIN
        SELECT RAISE(ABORT, 'constraint failed;'); -- Inlined SQL comment
    END;
    -- Standalone SQL; comment; with semicolons;
    INSERT INTO parent (a, b, c, d) VALUES ('pippo;', 'pluto;', NULL, NULL);
SQL
    
    use SQL::SplitStatement;
    
    my $sql_splitter = SQL::SplitStatement->new;
    my @statements = $sql_splitter->split($sql_code);
    
    # @statements now is:
    #
    # (
    #     'CREATE TABLE parent(a, b, c   , d    )',
    #     'CREATE TABLE child (x, y, "w;", "z;z")',
    #     'CREATE TRIGGER "check;delete;parent;" BEFORE DELETE ON parent WHEN
    #     EXISTS (SELECT 1 FROM child WHERE old.a = x AND old.b = y)
    # BEGIN
    #     SELECT RAISE(ABORT, \'constraint failed;\');
    # END',
    #     'INSERT INTO parent (a, b, c, d) VALUES (\'pippo;\', \'pluto;\', NULL, NULL)'
    # )

DESCRIPTION

This is a simple module which tries to split any SQL code, even including non-standard extensions (for the details see the "SUPPORTED DBMSs" section below), into the atomic statements it is composed of.

The logic used to split the SQL code is more sophisticated than a raw split on the ; (semicolon) character: first, various different statement terminator tokens are recognized (see below for the list), then this module is able to correctly handle the presence of said tokens inside identifiers, values, comments, BEGIN ... END blocks (even nested), dollar-quoted strings, MySQL custom DELIMITERs, procedural code etc., as (partially) exemplified in the "SYNOPSIS" above.

Consider however that this is by no means a validating parser (technically speaking, it's just a context-sensitive tokenizer). It should rather be seen as an in-progress heuristic approach, which will gradually improve as bugs will be reported. This also means that, with the exception of the "LIMITATIONS" detailed below, there are no known (to the author) SQL constructs the most current release of this module can't handle.

If your atomic statements are to be fed to a DBMS, you are encouraged to use DBIx::MultiStatementDo instead, which uses this module and also (optionally) offers automatic transactions support, so that you'll have the all-or-nothing behavior you would probably want.

METHODS

new

  • SQL::SplitStatement->new( %options )

  • SQL::SplitStatement->new( \%options )

It creates and returns a new SQL::SplitStatement object. It accepts its options either as a hash or a hashref.

new takes the following Boolean options, which all default to false.

  • keep_terminators

    A Boolean option which causes, when set to a false value (which is the default), the trailing terminator tokens to be discarded in the returned atomic statements. When set to a true value, the terminators are kept instead.

    If your statements are to be fed to a DBMS, you are advised to keep this option to its default (false) value, since some drivers/DBMSs don't want the terminator to be present at the end of the (single) statement.

    The strings currently recognized as terminators (depending on the context) are:

    • ; (the semicolon character).

    • / (the forward-slash character).

    • A semicolon followed by a forward-slash on its own line. This latter string is treated as a single token (it is used to terminate PL/SQL procedures).

    • Any string defined by the MySQL DELIMITER command.

    (Note that the last, possibly empty, statement of a given SQL text, never has a trailing terminator. See below for an example.)

  • keep_terminator

    An alias for the the keep_terminators option explained above. Note that if keep_terminators and keep_terminator are both set at object construction time, new throws an exception.

  • keep_extra_spaces

    A Boolean option which causes, when set to a false value (which is the default), the spaces (\s) around the statements to be trimmed. When set to a true value, these spaces are kept instead.

    When keep_terminators is set to false as well, the terminator is discarded first (regardless of the spaces around it) and the trailing spaces are trimmed then. This ensures that if keep_extra_spaces is set to false, the returned statements will never have trailing (nor leading) spaces, regardless of the keep_terminators value.

  • keep_comments

    A Boolean option which causes, when set to a false value (which is the default), the comments to be discarded in the returned statements. When set to a true value, they are kept with the statements instead.

    Both SQL and multi-line C-style comments are recognized.

    When kept, each comment is returned in the same string with the atomic statement it belongs to. A comment belongs to a statement if it appears, in the original SQL code, before the end of that statement and after the terminator of the previous statement (if it exists), as shown in this pseudo-SQL snippet:

        /* This comment
    will be returned
    together with statement1 */
    
    <statement1>; -- This will go with statement2
                  -- (note the semicolon which closes statement1)
    
    <statement2>
    -- This with statement2 as well

  • keep_empty_statements

    A Boolean option which causes, when set to a false value (which is the default), the empty statements to be discarded. When set to a true value, the empty statements are returned instead.

    A statement is considered empty when it contains no characters other than the terminator and space characters (\s).

    A statement composed solely of comments is not recognized as empty and may therefore be returned even when keep_empty_statements is false. To avoid this, it is sufficient to leave keep_comments to false as well.

    Note instead that an empty statement is recognized as such regardless of the value of the options keep_terminators and keep_extra_spaces.

These options are basically to be kept to their default (false) values, especially if the atomic statements are to be given to a DBMS.

They are intended mainly for cosmetic reasons, or if you want to count by how many atomic statements, including the empty ones, your original SQL code was composed of.

Another situation where they are useful (in the general case necessary, really), is when you want to retain the ability to verbatim rebuild the original SQL string from the returned statements:

    my $verbatim_splitter = SQL::SplitStatement->new(
        keep_terminators      => 1,
        keep_extra_spaces     => 1,
        keep_comments         => 1,
        keep_empty_statements => 1
    );
    
    my @verbatim_statements = $verbatim_splitter->split($sql_string);
    
    $sql_string eq join '', @verbatim_statements; # Always true, given the constructor above.

Other than this, again, you are highly recommended to stick with the defaults.

split

  • $sql_splitter->split( $sql_string )

This is the method which actually splits the SQL code into its atomic components.

It returns a list containing the atomic statements, in the same order they appear in the original SQL code. The atomic statements are returned according to the options explained above.

Note that, as mentioned above, an SQL string which terminates with a terminator token (for example a semicolon), contains a trailing empty statement: this is correct and it is treated accordingly (if keep_empty_statements is set to a true value):

    my $sql_splitter = SQL::SplitStatement->new(
        keep_empty_statements => 1
    );
    
    my @statements = $sql_splitter->split( 'SELECT 1;' );
    
    print 'The SQL code contains ' . scalar(@statements) . ' statements.';
    # The SQL code contains 2 statements.

split_with_placeholders

  • $sql_splitter->split_with_placeholders( $sql_string )

It works exactly as the split method explained above, except that it returns also a list of integers, each of which is the number of the unnamed placeholders contained in the corresponding atomic statement.

More precisely, its return value is a list of two elements, the first of which is a reference to the list of the atomic statements exactly as returned by the split method, while the second is a reference to the list of the number of placeholders as explained above.

Currently the only recognized placeholders are the ? (question mark) characters.

Here is an example:

    # 4 statements (valid SQLite SQL)
my $sql_code = <<'SQL';
    CREATE TABLE state (id, name);
    INSERT INTO  state (id, name) VALUES (?, ?);
    CREATE TABLE city  (id, name, state_id);
    INSERT INTO  city  (id, name, state_id) VALUES (?, ?, ?)
SQL
    
    my $splitter = SQL::SplitStatement->new;
    
    my ( $statements, $placeholders )
        = $splitter->split_with_placeholders( $sql_code );
    
    # $placeholders now is: [0, 2, 0, 3]

where the returned $placeholders list(ref) is to be read as follows: the first statement contains 0 placeholders, the second 2, the third 0 and the fourth 3.

keep_terminators

  • $sql_splitter->keep_terminators

  • $sql_splitter->keep_terminators( $boolean )

    Getter/setter method for the keep_terminators option explained above.

keep_terminator

An alias for the keep_terminators method explained above.

keep_extra_spaces

  • $sql_splitter->keep_extra_spaces

  • $sql_splitter->keep_extra_spaces( $boolean )

    Getter/setter method for the keep_extra_spaces option explained above.

keep_comments

  • $sql_splitter->keep_comments

  • $sql_splitter->keep_comments( $boolean )

    Getter/setter method for the keep_comments option explained above.

keep_empty_statements

  • $sql_splitter->keep_empty_statements

  • $sql_splitter->keep_empty_statements( $boolean )

    Getter/setter method for the keep_empty_statements option explained above.

SUPPORTED DBMSs

SQL::SplitStatement aims to cover the widest possible range of DBMSs, SQL dialects and extensions (even proprietary), in a fully transparent way for the user.

Currently it has been tested mainly on SQLite, PostgreSQL, MySQL and Oracle.

LIMITATIONS

To be split correctly, the given SQL code is subject to the following limitations, mainly concerning procedural code (the limitation about the use of some keywords as unquoted identifiers affecting the previous releases, has now been eliminated).

  • Procedural extensions

    Currently any block of code which start with DECLARE, CREATE or CALL is correctly recognized, as well as bare BEGIN ... END blocks and dollar quoted blocks, therefore a wide range of procedural extensions should be handled correctly. However, only PL/SQL, PL/PgSQL and MySQL code has been tested so far.

    If you need also other procedural languages to be recognized, please let me know (possibly with some test cases).

  • PL/SQL

    If a package contains also an initialization block, then it must terminate with a semicolon and a slash, or it must have the package name after the END of package (which is the recommended practice anyway).

    For example, these two package (pseudo-)definitions will be correctly split:

        -- OK since it has the trailing slash
    CREATE OR REPLACE PACKAGE BODY my_package AS
        ...
    BEGIN
        ...
    END;
    /
    
    -- OK since it has the package name after the END
    CREATE OR REPLACE PACKAGE BODY my_package AS
        ...
    BEGIN
        ...
    END my_package;

    while this one wouldn't, since it contains an initialization block and it lacks both the package name after the END and the trailing slash:

        CREATE OR REPLACE PACKAGE BODY my_package AS
        ...
    BEGIN -- initialization block starts here
        ...
    END;

    Note however that if the initialization block is absent, the package block will be correctly isolated even if it lacks both the package name after the END and the trailing slash.

Non-limitations

To be split correctly, the given input must, in general, be syntactically valid SQL. For example, an unbalanced BEGIN or a misspelled keyword could, under certain circumstances, confuse the parser and make it trip over the next statement terminator, thus returning wrongly split statements. This should not be a problem though, as the original (invalid) SQL code would have been unusable anyway (remember that this is NOT a validating parser!)

DEPENDENCIES

SQL::SplitStatement depends on the following modules:

AUTHOR

Emanuele Zeppieri, <emazep@cpan.org>

BUGS

No known bugs.

Please report any bugs or feature requests to bug-sql-SplitStatement at rt.cpan.org, or through the web interface at http://rt.cpan.org/NoAuth/ReportBug.html?Queue=SQL-SplitStatement. I will be notified, and then you'll automatically be notified of progress on your bug as I make changes.

SUPPORT

You can find documentation for this module with the perldoc command.

    perldoc SQL::SplitStatement

You can also look for information at:

ACKNOWLEDGEMENTS

Igor Sutton for his excellent SQL::Tokenizer, which made writing this module a joke.

SEE ALSO

LICENSE AND COPYRIGHT

Copyright 2010-2011 Emanuele Zeppieri.

This program is free software; you can redistribute it and/or modify it under the terms of either: the GNU General Public License as published by the Free Software Foundation, or the Artistic License.

See http://dev.perl.org/licenses/ for more information.