You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While I generally approve of the ability to use actual PostgreSQL prepared statements when calling prepareStatement(), this comes with limitations that can make prepared statements impractical:
For use cases where it is not possible to reuse statements, prepared statements come with a performance penalty that grows with latency (see also PreparedStatement performance issue #59). We have users with network latency in the 1-10 ms range and need to be mindful of the number of messages that bounce between the application and database, especially for trivial queries. For 100 queries a user could wait one second just due to network latency, and the extra step for parsing/preparing the query and getting metadata doubles that time.
PostgreSQL does not permit execution of multiple commands in a single prepared statement, so if we batch commands in the application to reduce network penalty then prepareStatement() fails.
This is problematic because prepared statements happen to be the recommended best practice for preventing SQL injection attacks. I am not comfortable with building the entire SQL query by concatenating SQL and user-provided parameters just to be able to call createStatement() instead of prepareStatement(). So I propose some extension to the JDBC API that lets me indicate whether prepareStatement() should actually use a PostgreSQL prepared statement or whether I just want an non-prepared statement but with support for placeholders, preferably on a per-statement basis.
The text was updated successfully, but these errors were encountered:
While I generally approve of the ability to use actual PostgreSQL prepared statements when calling prepareStatement(), this comes with limitations that can make prepared statements impractical:
This is problematic because prepared statements happen to be the recommended best practice for preventing SQL injection attacks. I am not comfortable with building the entire SQL query by concatenating SQL and user-provided parameters just to be able to call createStatement() instead of prepareStatement(). So I propose some extension to the JDBC API that lets me indicate whether prepareStatement() should actually use a PostgreSQL prepared statement or whether I just want an non-prepared statement but with support for placeholders, preferably on a per-statement basis.
The text was updated successfully, but these errors were encountered: