Hacker News Reader

Comment by mschuster91 | Hacker News Reader

> A side effect of using transaction pooling is that you cannot use prepared statements, as the PREPARE and EXECUTE commands may end up running in different connections; producing errors as a result.

Uhhh... WHAT? I'll simply sit by and watch for SQL injection vulnerabilities resulting from this change. Either you have a very good SQL query writer engine with rock solid escaping or you will get pwned by this.

View on HN

You can have perfectly valid input escaping without needing prepared statements. Many ORMs handle this without the need for PREPARE/EXECUTE.

> You can have perfectly valid input escaping without needing prepared statements.

People have bypassed this far too often for my taste, and there is a reason why SQL (and other injections) are Top 1 of OWASP (1st place actually, both in RC1 and 2 of 2017, but also in the 2013 edition).

Never, ever trust any form of escaping or it will bite you. Hard.

> Never, ever trust any form of escaping or it will bite you. Hard.

This is an absurd dogmatic statement. Everybody trusts a multitude of escapings everywhere every day all over the web without even knowing it.

How much do you trust the postgres developers?

https://www.postgresql.org/docs/9.1/static/libpq-exec.html#L...

What is transaction pooling anyway? A transaction exists for a specific action, it shouldn't be shared among users or multiple connections. It sounds like they've taken transactions and removed the isolation.

I don't know what the data access is like, but I get the impression that it's like some "enterprise" patterns I've seen where data access is too "encapsulated", ie, each DAL opens it's own connection, pulls it's chunk of data and each request involves many of these instead of having each request open the connection and pass it down to the data access layers.

"transaction-level" pooling might be a more apt description. Instead of assigning each incoming connection to a dedication upstream connection for the entire duration of the incoming connection, it assigns the upstream connections on a per-transaction basis. When each transaction ends, the upstream connection is returned to the pool. A better description is at https://wiki.postgresql.org/wiki/PgBouncer.

In Postgres, beyond the SQL PREPARE commands, there is also a protocol for executing prepared statements. Their client drivers almost certainly use this protocol, which would mean the normal placeholder safety applies. I think this is just a misunderstanding of their point, and not a full backtracking to string escaping.

Reply on news.ycombinator.com