-
Notifications
You must be signed in to change notification settings - Fork 122
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for prepared statements and placeholders #45
Comments
@nvx There is no technical limitations on the nginx side except the lack of tagging support in the standard ngx_http_upstream_keepalive module (where we need to tag in-pool connections with their prepared statements). Well, patches welcome :) |
@nvx Oh, please ignore the ngx_http_upstream_keepalive_module part in my previous comment. The ngx_postgres module implements its own connection pool anyway. So there's no issues here. |
Ah interesting point. My comment on technical limitation was actually thinking on the configuration side if the nginx config parser was able to cope with vararg-like statements. I haven't done any work with nginx plugins themselves before, so wondered if that was a blocker to implementing this. |
@nvx Yes, nginx directives can accept a variable number of arguments. This is not a problem. I just hope that the user does not have to prepare the same statement upon every request if the Pg connection is reused via the pool. That is, we just have to prepare the statement once for every single Pg connection (yes, this is the real performance benefit of preparing a statement and then executing it over and over again). So tagging connections in pool somehow is important for such stateful treatment. |
The current way of passing untrusted user input is via manually escaping and then forming the sql query with the escaped values.
This is prone to human error and could result in sql injection attacks being possible.
The ideal situation would be to add support for prepared statements using placeholders. Is there any technical limitation of the nginx engine preventing this?
The text was updated successfully, but these errors were encountered: