Problem/Motivation
For performance reasons we currently force PostgreSQL to use emulated prepares:
// Prepared statements are most effective for performance when queries
// are recycled (used several times). However, if they are not re-used,
// prepared statements become inefficient. Since most of Drupal's
// prepared queries are not re-used, it should be faster to emulate
// the preparation than to actually ready statements for re-use. If in
// doubt, reset to FALSE and measure performance.
\PDO::ATTR_EMULATE_PREPARES => TRUE,
But that's a bad idea, because of:
Postgres PDO Driver uses native statement preparation by default. PDO MySQL uses emulated prepares by default. Native prepares are much more robust against SQL injection, so should be used if at all possible.
Proposed resolution
Re-think the current default to emulate prepares. Check if this is still a performance issue in Drupal 8, and if not, revert back to default to make PostgreSQL more robust against SQL injections.
Remaining tasks
?
User interface changes
none
API changes
none
Comments
Comment #1
pwolanin commentedThere is an issue about using native prepares for MySQL also - seems the issues should be coupled?
Comment #2
bzrudi71 commentedWell, let's actually test this now that we have a green PG bot...
Comment #5
bzrudi71 commentedwell, let's see :)
Comment #6
bzrudi71 commentedComment #7
bzrudi71 commentedComment #8
bzrudi71 commentedComment #9
bzrudi71 commentedI'm going to close this one. Test time increased just a bit but what makes me more worry is that we have lot's of memory exceptions. And as #2489672: Limit all DB drivers to executing single statements by checking for delimiter is in now I don't think it's worth the effort ;-)
Feel free to open this issue again if any ideas or concerns...