Unlike other drivers, DBAL has a hard dependency on PDO

[morozov]

Historically, the DBAL public API uses PDO constants which creates a hard dependency and makes the abstraction not that abstract. For the end user, it means that even if none of the PDO drivers are going to be used, the production environment still has to have ext-pdo installed.

To eliminate the dependency, the PDO constants in the method signatures should be replaced by the DBAL's own ones:

1. PDO::PARAM_* → Doctrine\DBAL\Driver\Statement::PARAM_*,
2. PDO::FETCH_* → Doctrine\DBAL\Driver\ResultStatement::FETCH_*,
3. PDO::CASE_* → Doctrine\DBAL\Driver\ResultStatement::CASE_*.

It can be done in phases:

1. In 2.x, introduce the new DBAL constants and assign them corresponding PDO values, e.g. Statement::PARAM_INT = PDO::PARAM_INT.
2. Deprecate the usage of PDO:: constants when calling the DBAL methods.
3. In 3.0, replace the PDO constants with their integer values, e.g. Statement::PARAM_INT = 1
4. Remove the dependency.

[morozov]

So far, I've stumbled upon unclear issues:

1. ResultStatement::fetch() declares support of PDO::FETCH_ORI_* constants. In fact, they are only supported by PDO. Most likely, they are not used anywhere and therefore can be dropped.
2. Statement::bindParam() declares support of PDO::PARAM_INPUT_OUTPUT. Given it can only be used with stored procedures which the DBAL doesn't support, there's no way it could be used and therefore its support can be dropped.

Please let me know if you know the reason why the functionality defined by those constants should be still supported.

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.