@oshai can you help me with this?

Run gradle/wrapper-validation-action@e6e38bacfdf1a337459f332974bb2327a31aaf4b
  with:
    min-wrapper-count: 1
    allow-snapshots: false
  env:
    JAVA_HOME: /opt/hostedtoolcache/Java_Adopt_jdk/8.0.45[2](https://github.com/jasync-sql/jasync-sql/actions/runs/15515837938/job/43682601835#step:4:2)-9/x64

What do I have to fix?

@oshai can you help me with this?

Run gradle/wrapper-validation-action@e6e38bacfdf1a337459f332974bb2327a31aaf4b
  with:
    min-wrapper-count: 1
    allow-snapshots: false
  env:
    JAVA_HOME: /opt/hostedtoolcache/Java_Adopt_jdk/8.0.45[2](https://github.com/jasync-sql/jasync-sql/actions/runs/15515837938/job/43682601835#step:4:2)-9/x64

What do I have to fix?

I just rerun it, hth.

@oshai Thx. Please review my code then.😃

I guess for the long run it makes more sense to support in (?) with list support?

can mysql client/server protocol pass a list object in one placeholder like that?

@oshai You're right. In JDBC

It supports the SQL ARRAY data type. However, MySQL doesn't have an ARRAY type, unlike PostgreSQL.

So, perhaps I can adapt this code for PostgreSQL?

yes, I think postgres will better fit here. for mysql you can see what the jdbc mysql driver does (it still needs to support arrays) and do something similar.

Hi @oshai,

Proposal: Safe List Expansion for IN Clauses

After careful review, our most robust and safest path forward is to support list expansion for IN clauses exclusively when using named parameters, across all supported databases. This approach aligns with how Spring JDBC handles such scenarios.

Why Automatic Expansion for Positional Placeholders is Unsafe

Attempting to automatically expand positional ? placeholders is inherently unsafe due to the tight coupling it creates between the Java parameter order and the SQL query's structure.

Consider a query like:

SET status = ? WHERE id IN (?)

If the library were to automatically expand IN (?), it would have to guess the developer's intent based on the parameter order. Should the SQL ever be refactored (e.g., to WHERE id IN (?) SET status = ?), a developer would also need to remember to reorder the Java parameters accordingly. This introduces fragility and makes the code difficult to maintain.

The Advantage of Named Parameters

Named parameters, such as :ids, completely eliminate this risk by removing any dependency on parameter order. This ensures clarity and maintainability.

Final Implementation Plan

Based on this analysis, our final implementation plan is as follows:

• For Named Parameter Queries: We will implement client-side rewriting.
  • For example, IN (:ids) will be expanded to IN (?, ?, ?) for databases like MySQL.
• For Positional ? Queries: We will not implement any automatic expansion. Users will be expected to build the IN clause manually. This maintains the standard, predictable, and safe behavior.

This approach allows us to provide a powerful convenience feature—list expansion in IN clauses—in a predictable and safe manner, without the inherent dangers of adding "magic" to ambiguous placeholders.

What are your thoughts on this direction?

Currently the driver do not support named params at all. But when using with the r2dbc adapter it add such support iirc.

So I don't know if adding such support is beneficial. It will require us in the client side to parse the statement which we don't do right now (might impct performance, be fragile, etc')

So I would start with just supporting it in postgres by sending array param.

@oshai ok~ I see.

So in postgres does it gonna change like = ANY(array['Ava', 'Dave']) ?

Not sure I follow.