paulk-asert opened a new pull request, #2866:
URL: https://github.com/apache/groovy/pull/2866

   … text
   
   Inside withBatch { ... } the wrapper's only SQL-accepting method takes a 
String, so a GString handed to it is coerced and its values become part of the 
statement. Every query method on Sql binds the same idiom, and the class 
documentation said so without qualification, so the one surface where it does 
not hold read exactly like the ones where it does.
   
   It is documented rather than rejected. A JDBC Statement batch may hold 
different statements, which is why it takes text and has nothing to bind 
against, and there is no parameterized equivalent to send callers to: batching 
heterogeneous statements, generated DDL, and identifiers that cannot be bound 
are all legitimate here. The module's own SqlBatchTest uses this idiom. 
Rejecting would remove a capability with no replacement, which is the same test 
applied to the quoted-expression case that is rejected precisely because 
removing the quotes costs nothing.
   
   So: an addBatch(GString) overload that renders and adds the command as 
before, and logs once per batch when a value was composed in that was not 
marked with Sql.expand. That mirrors asSql, which warns whenever it inlines 
rather than binds; the difference is that inlining is the only option here, so 
there is no strict mode to fall back from. Deliberate interpolation marked with 
Sql.expand passes quietly and now substitutes the expanded value, which plain 
GString rendering did not do.
   
   The documentation is the substance of the fix: the class-level guidance now 
carries the exception, both withBatch forms that hand out this wrapper say the 
commands are text, and addBatch says it on the method itself.
   
   P1 gains the rule that settles the finding's disposition: an API qualifies 
when it has a GString form that binds, so this surface is outside P1 rather 
than violating it, and the obligation is to say so and report the coercion.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to