Summary

The current SQL parser implementation allows certain usages that are rather a side effects of the existing implementation than something that the implementation was purposefully designed for.

1. The keys of positional parameters and their types can be anything and do not have to correspond to the positions of the placeholders in the statement. This is achieved by sorting them:

   dbal/lib/Doctrine/DBAL/SQLParserUtils.php

   Lines 152 to 153 in 99f9c7e

   	ksort($params);
   	ksort($types);

   and then discarding keys:

   dbal/lib/Doctrine/DBAL/SQLParserUtils.php

   Lines 177 to 178 in 99f9c7e

   	$params = array_values($params);
   	$types = array_values($types);

   And is even covered by a test:

   dbal/tests/Doctrine/Tests/DBAL/SQLParserUtilsTest.php

   Lines 313 to 333 in 99f9c7e

   	'Positional starts from 1: One non-list before and one after list-needle' => [
   	'SELECT * FROM Foo WHERE foo = ? AND bar IN (?) AND baz = ? AND foo IN (?)',
   	[1 => 1, 2 => [1, 2, 3], 3 => 4, 4 => [5, 6]],
   	[
   	1 => ParameterType::INTEGER,
   	2 => Connection::PARAM_INT_ARRAY,
   	3 => ParameterType::INTEGER,
   	4 => Connection::PARAM_INT_ARRAY,
   	],
   	'SELECT * FROM Foo WHERE foo = ? AND bar IN (?, ?, ?) AND baz = ? AND foo IN (?, ?)',
   	[1, 1, 2, 3, 4, 5, 6],
   	[
   	ParameterType::INTEGER,
   	ParameterType::INTEGER,
   	ParameterType::INTEGER,
   	ParameterType::INTEGER,
   	ParameterType::INTEGER,
   	ParameterType::INTEGER,
   	ParameterType::INTEGER,
   	],
   	],

2. The parser allows omitting parameters.
3. The parser allows mixing positional and named parameters in the same statement (this is currently forbidden by the documentation and wouldn't be a BC break):

   dbal/docs/en/reference/data-retrieval-and-manipulation.rst

   Line 95 in 99f9c7e

   a double-colon (:name1). You cannot mix the positional and the named approach. The approach

The behavior above should be deprecated in order to allow future rework of the parser w/o introducing breaking changes.