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
{{ message }}
Repository navigation
sqlc.slice() breaks SQLite queries that contain other parameters. #2452
Just ran into this. Is there a reason the SQLite engine can't use named parameters? If I were to submit a PR to switch to using named params for both non-slice params and generated names for slice params ((sqlc.slice('my_slice')) => (@my_slice__1, @my_slice__2, @my_slice__3)) would that be considered for acceptance?
I've run into the same issue. I have this SQL code:
-- name: GetRuns :manySELECT runs.*, scenarios.nameAS scenario_name
FROM runs
JOIN scenarios
ONscenarios.id=runs.scenario_idWHERE
(timestamp>sqlc.narg('run_date_after') OR @run_date_after IS NULL)
AND (timestamp<sqlc.narg('run_date_before') OR @run_date_before IS NULL)
AND (status IN (sqlc.slice('filter_run_status')))
AND (scenarios.name=sqlc.narg('filter_scenario_name') OR @filter_scenario_name IS NULL);
And it gets compiled into this query:
-- name: GetRuns :manySELECTruns.id, runs.timestamp, runs.status, scenarios.nameAS scenario_name
FROM runs
JOIN scenarios
ONscenarios.id=runs.scenario_idWHERE
(timestamp> ?1OR ?1 IS NULL)
AND (timestamp< ?2OR ?2 IS NULL)
AND (status IN (?,?,?,?))
AND (scenarios.name= ?4OR ?4 IS NULL)
The whole ?2, ?, ?4 causes the query to not match anything when the parameters are substituted, and no error is thrown. However if I rearrange the WHERE clause so that the sqlc.slice comes at the end, things seem to work as expected.
I'd love to look into patching this. @kyleconroy any pointers on where to look first? So far, the only solution I see is to replace numbered placeholders on query execution dynamically, adding the size of the slice (for example, if the slice is the first placeholder, replacing ?2 to ?(1 + length of the slice)
Same here with SQLite. I'll try a fix in the generated code to see if a solution can be applied.
EDIT: I think this should be handled during the generation. For example, if the /*SLICE:col*/?, then the numbered parameters should be assigned at runtime (at least, if it's not the last parameter). It would be an extra cost for the query, but there is no way to know how many parameters there will be before having the actual slice.
For the time being, I just copy/paste the generated code in a internals/database/users.raw.go and modify it for my use.
Activity
ciarand commentedon Sep 7, 2023
Just ran into this. Is there a reason the SQLite engine can't use named parameters? If I were to submit a PR to switch to using named params for both non-slice params and generated names for slice params (
(sqlc.slice('my_slice'))=>(@my_slice__1, @my_slice__2, @my_slice__3)) would that be considered for acceptance?bengesoff commentedon Jan 31, 2024
I've run into the same issue. I have this SQL code:
And it gets compiled into this query:
The whole
?2,?,?4causes the query to not match anything when the parameters are substituted, and no error is thrown. However if I rearrange theWHEREclause so that thesqlc.slicecomes at the end, things seem to work as expected.sybrenstuvel commentedon Jun 8, 2024
I'm running into the same thing. IMO this should at least be included in the documentation as something to be cautious about.
traut commentedon May 23, 2025
I'm hitting the same issue. This looks like a major bug! I hope it will get resolved.
traut commentedon Aug 4, 2025
I'd love to look into patching this. @kyleconroy any pointers on where to look first? So far, the only solution I see is to replace numbered placeholders on query execution dynamically, adding the size of the slice (for example, if the slice is the first placeholder, replacing
?2to?(1 + length of the slice)iivvaannxx commentedon Oct 10, 2025
Ran into the same issue with SQLite☹️
michaeldebetaz commentedon Oct 15, 2025
Same here with SQLite. I'll try a fix in the generated code to see if a solution can be applied.
EDIT: I think this should be handled during the generation. For example, if the
/*SLICE:col*/?, then the numbered parameters should be assigned at runtime (at least, if it's not the last parameter). It would be an extra cost for the query, but there is no way to know how many parameters there will be before having the actual slice.For the time being, I just copy/paste the generated code in a
internals/database/users.raw.goand modify it for my use.