-
Notifications
You must be signed in to change notification settings - Fork 2.3k
Buffer overflow when using too many parameters #201
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
Comments
That is definitely a corner case. But we should fix it nevertheless. If possible, you should avoid to use of "SELECT IN". If the IDs are not already saved in the same database, you should try to make them available there. Then you can just use a JOIN, which probably performs a lot better. |
If you know the number of placeholders in advance, do you know the values, too? Esp. if it's an id, just build the query string. Correct me if I'm wrong, but that's all ints you know beforehand, right? Then there's no reason to protect against an injection attack. Just bake them into your query, that's faster because the parameters don't have to be sent in an extra packet. I'm still with @julienschmidt, we should fix that. |
Unfortunately it's a situation where I have to pass in many id's to select-in from. I like the idea of building the query though, I'll try it out when I need a performance boost. Thanks! |
Closing this, further comments in #210 please. |
I had some very long queries that were panic'ing on array out-of-bounds on the following line:
The query basically had some 2100+ placeholders like
Select * from myTable where id in (?,?,?,?,....?)
.The following change seems to have fixed it:
jaekwon@25a9fdb
It's hacky though so perhaps a refactoring is in order.
Is there a better way to pass in many id's in a SELECT-IN query?
The text was updated successfully, but these errors were encountered: