[orf]

I think your argument is “if I try hard enough to make what I want to do really hard, it will be really hard”. I agree. I’m not sure I buy your argument about ORMs being limiting, given your current… limitations.

Of course you could just do CAST(? AS …) or use something like “string_to_array(?)”. But that’s just working around not being able to compose queries.

[8n4vidtmkvmk]

Some of my queries get quite complicated, but I'm good at writing SQL. Why would I want to mess around with an ORM trying to recreate the SQL I actually want?

CAST() what? I apologize, the example was a bad. I don't want an array on the SQL side, I want to supply an array. Something more like

SELECT * FROM foo WHERE x=? AND y IN (?)

If I pass [1,[2,3]]

It should expand to

SELECT * FROM foo WHERE x=1 AND y IN (2,3)

Which means it actually needs to be written as

SELECT * FROM foo WHERE x=? AND y IN (?, ?)

And I'd have to pass [1,2,3].

At least in all the DB connectors I've seen. I mostly use MariaDB.

[orf]

Oh, right, that’s the same problem with the same solution though.

Parameters supply only values, but the cases you’ve shown require expressions. Of course no database (or db connector) would work like that, it’s slightly nonsensical. In your specific example the cardinality of the IN clause is important to the plan.

But all in all, congratulations, you’ve come to reach the limits of using raw SQL with dynamic inputs. Your choices are now: build an ORM, use an ORM, or hack around this issue with code that will horrify the next person to work on it. shrug.

[8n4vidtmkvmk]

I hacked it with regexes to expand out the ?s. Maybe it'll mangle a query one day but I don't see how it could be injected. The only issue I ran into in ~10 years now is on bigass queries my regex was a bit slow because I trying to handle the string case properly. I found a way to speed it up though.