Fix handling of deferred constraints

[Thomasdezeeuw]

Currently this for PostgreSQL only, but if the fix would be accepted I can apply it to the other databases as well.

Fixes #1370

[abonander]

I'll accept this but do note:

The MySQL driver would need some tweaking in order for there to not be a performance footgun by using .fetch_optional() without LIMIT 1. Right now it doesn't do anything to limit the size of the resultset, so .fetch_optional() would have to wait until the server is finished sending all of it to get the result. That's a large reason why the current implementation is how it is, to be consistent for all drivers.

It looks like it's possible to limit the number of rows returned by setting the flag to request a cursor and then calling COM_STMT_FETCH on that cursor, but it sounds like the cursor type depends on what kind of query you're executing? The MariaDB docs explain it a little better than the MySQL docs but only slightly: https://mariadb.com/kb/en/com_stmt_execute/#flag

vs: https://dev.mysql.com/doc/dev/mysql-server/latest/page_protocol_com_stmt_execute.html

If I had to hazard a guess, I think requesting a "for update" cursor means you're allowed to send a data-modifying query while still having it open. It must make a copy of the dataset or something. Whereas a "read only" cursor would forbid a concurrent query and read data directly from the table. I think the latter is a safe choice as I don't think we'd ever want to allow that. It'd just be a massive footgun.