Repository navigation
Parameters instead of structs #2098
Description
Activity
Presumably the choice to use structs as function arguments was to avoid creating super-long function signatures, which are unwieldy. Maybe this could be a configuration option that doesn't change default behavior?
Sure as an optional configuration. For me I would be ok to have those long param lists, but have the compiler check for missing params. Would save a bunch of tests
@polderudo Could you take a look at #1558? It would solve your problem, but would change all queries in a sqlc project.
Reacted by Josh Bleecher Snyder and Samuel Mortenson@polderudo Could you take a look at #1558? It would solve your problem, but would change all queries in a sqlc project.
Yes, that would definitely solve my issue. I would use 999 for that parameter then :)
I like params, but since a default "empty" value can be a bit dangerous in a query I started using a CI check to enforces that all params are always explicitly defined using exhaustruct:
exhaustruct -i '.*db\..*' <your module name>Where
dbis the name of my sqlc module that defines param-structs.Closing since we now have the
query_parameter_limitoption.
What do you want to change?
Right now, when we do an insert/update/select sqlc generates a struct for the needed sql-parameters most time.
If one changes a parsed query (e.g. add a new param), the generated struct also changes. Now we have to check every single location, where the struct is used, in order to be sure, that we populate the struct with all new values, else the go default values will be used for that fields.
It would be a very helpfull feature, if we could have the values just as regular params on the query function. The compiler would warn if we miss a value. Maybe create the struct inline and use it only inside the functions, so we don't have to change the other functionality?
What database engines need to be changed?
No response
What programming language backends need to be changed?
Go