Open roookeee opened 2 years ago
I suppose this works fine with regular positional parameters (where we do not parse the provided SQL ourselves), and you are effectively asking for NamedParameterJdbcTemplate
support for VALUES
, expanding a nested named parameter accordingly?
I suppose this works fine with regular positional parameters (where we do not parse the provided SQL ourselves), and you are effectively asking for
NamedParameterJdbcTemplate
support forVALUES
, expanding a nested named parameter accordingly?
Yes, this is correct. Spring Data JDBC uses NamedParameterJdbcTemplate
and it's named parameters exclusively.
@jhoeller, I can prepare a PR for this, but I'm not sure if such a feature belongs in the framework, as it is not supported by jdbc statements.
Preamble: I have been sent here by @schauder in spring-data-relational in regards to https://github.com/spring-projects/spring-data-relational/issues/1300.
Currently
JdbcTemplate
does not supportSELECT
statements that use theVALUES
keyword. Here is an example from spring-data-jdbc that usesJdbcTemplate
under the hood::ids
is not properly expanded (it needs to put every list entry into()
) and thus generates wrong SQL. I know this would be complex to support for complex objects types asIN
-statements works with tuples in some databases but the simple, one-valued variant should be pretty straightforward.At least PostgreSQL generates different plans for a simple
IN
vsIN VALUES
clause, especially when the input list is big (>100) which perform quite differently (10-30% worse for us). Using aVALUES
list is also interesting when using CTE (WITH
) to populate a temporary table with user provided input, this is not achievable with anIN
statement.Disclaimer: I haven't checked if
VALUES
expansion works in customINSERTS