Heya. A recurring feature request (#2254,#2002 etc) is the ability to insert multiple rows at once.

For PostgreSQL we have CopyFrom support, which works quite well - but COPY FROM can only INSERT, so you need to use a temp table if you want some form of updating.

For MySQL I have PR#2220 pending, but MySQL's LOAD DATA LOCAL INFILE comes with a bunch of caveats that are scary. It is more powerful than Postgres's COPY FROM through, but I've yet to build support the LOAD DATA statement which actually allows using those features.

So that still leaves us with a niche unfilled: A simple INSERT INTO with multiple rows.

I've been looking into the design of it and ran into a few things I'd like to discuss.

1. How do we signal to sqlc that we want to use this bulk insert? I've consideredINSERT INTO table VALUES sqlc.repeat((?, ?, NOW())) but the parsers choke on that. My latest thinking is to useAllow for extra parameters to the queryType #2375 and have the syntax-- name: MultipleInsert :execrows multiple.
2. Method signature: I propose to simply refuse any parameters outside of the to-be-inserted row, so the argument can simply be a slice.
3. Implementation: I'm thinking to split the query into three parts: the prologue:INSERT INTO table VALUES, a repeatable(?, ?, NOW()) and the epilogue ON CONFLICT .... However, it's proven non-trivial to extract that from the sql parsers. PostgreSQL's AST only exposes this for A_Const nodes (Expose node position in input string pganalyze/pg_query_go#90). MySQL exposes positions of AST nodes, but not lengths - so we can't find the parentheses of the values with 100% certaintly. The sqlite parser seems to expose positions, so that's at least easy. pg_query_go and tidb/parser do expose their scanners/lexers though, so we could probably use that to parse simple queries. That does add an entire parsing path for each engine however.Or we could just use a simple regexp ;)