Re: [h2] Question about JDBC prepared statements in H2

On 11/7/2022 4:59 PM, Silvio wrote: I was hoping for perhaps some speedup if the query planner could make a more optimal query plan based on known values in the SQL string as opposed to a more generic query plan that would have to take all possible values for one or more parameters into acc

Re: [h2] Question about JDBC prepared statements in H2

Thanks Noel. String values are exactly what we where planning to keep as parameters. So in many cases one or more parameters will remain (for string values) but most will be replaced by literals since in our case by far most column types are numeric, timestamp or UUID. I was hoping for perhaps

Re: [h2] Question about JDBC prepared statements in H2

I prefer PreparedStatement purely so I can avoid thinking about escaping string values. But if that doesn't worry you, then there is no down side to using Statement for execute only once. -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To unsu

[h2] Question about JDBC prepared statements in H2

Apart from SQL-injection considerations Is there any advantage or disadvantage in using PreparedStatement parameters versus literal values when the statement will only be executed once? Our generic database handling code currently uses statement parameters for all situations and column types. W