It seems doing 1. does not prevent us from doing 2. later if we want to introduce macros. Am I right?

Yes. The only issue would be that two different syntaxes would be used for plain parameters vs. macros, but I don't think that's a big problem. Plus, we could also allow parameters to be specified via our own syntax if people care about it.

If true, then I lean towards 1. first to get something out.

+1. As MongoDB doesn't offer parameterized queries, I'll give it a try with Neo4j (Davide D'Alto I don't think you have started with that, right?).

Btw Sanne, I disagree with you, the syntax proposed by Gunnar is valid escaping. {{ } }} is your exit sequence. Personally I think that something not involving bracket would be better due to the pervasive nature of JSON these days.

I chose the ${PARAM} syntax as it resembles EL expressions which I find quite appealing (one could theoretically even use an EL engine for evaluating function calls, access context objects and so on). But you're right that the potential for conflicts with JSON-based queries is too high.

By the way, I suspect we always know the input type and we could use the grid types to convert objects like Date into their native string representation. Any complication with that? I've problem as I mentioned in the discussion is that some parameters require to be quoted as some might not depending on their types (strings vs numbers).

I was wondering the same (see the first section of my previous comment). But would there still be a problem when we use the store's native named parameter facilities? I'd assume these to take "real" objects and not to expect a String representation to be passed. We have the GridType of the parameter value passed via setParameter() at hand; IIUC we can use that to convert the given value into the representation expected by the dialect which then would pass it to the store's/driver's named parameter API.