Many database engines can handle arrays, or table-valued variables which are basically the same thing. Most ORMs will also abstract away arrays for you, so you as the developer never need to deal with escaping of data in arrays.
If you're using an ORM/SQL builder, sure. If you prefer writing raw SQL because ORMs are often quite limiting, then you have to write something like `INSERT INTO foo VALUES ?` and then you pass it `[1, [2,3,4], 5]` as params, which is mostly fine but you still have to parse out that "?" from the query. Why parse? Because what if you wrote 'VALUES "?"' now it's a string and shouldn't be replaced. It would be much nicer if you could just send the query to the SQL server and figure out what to do with the params.
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.
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.