Re: Re: [RFC] Debugging PDO Prepared Statement Emulation
| From: | Adam Baratz | Date: | Wed, 26 Oct 2016 15:56:10 +0000 |
| Subject: | Re: Re: [RFC] Debugging PDO Prepared Statement Emulation | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-96616@lists.php.net to get a copy of this message | ||
>
> Since PDO is an interface to third party databases this seems totally
> out of place in PHP. Prepared statements are a sensible mechanism for
> for anyone wanting secure access to those database, so what is the point
> of this code.
I don't want to solve for database access. I want to create a testing tool
for emulated prepared statements. We already have
PDOStatement::debugDumpParams() for revealing some PDO internals. This
would offer another slice. I don't want to create another path for talking
to the database.
I updated the RFC introduction to make this clearer. I also added a
description of another use case (.phpt tests).
Older mysql did not have prepared queries hence the default of
> converting the more secure SQL into something old mysql could handle. I
> presume that dblib has the same fundamental problem? But mssql has
> prepared statements so dblib SHOULD provide that interface?
>
MSSQL understands prepared statements, but not through DB-Library. The API
dates back to the early '80s. It's really quite primitive. ODBC is the
"right" way to use prepared statements with MSSQL, but it's honestly not a
drop-in replacement.