Another option here would be to include this functionality in the .append() function.

Codecov Report

Merging #35 into master will not change coverage.
The diff coverage is 100%.

@@          Coverage Diff          @@
##           master    #35   +/-   ##
=====================================
  Coverage     100%   100%           
=====================================
  Files           1      1           
  Lines          28     32    +4     
=====================================
+ Hits           28     32    +4

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7d38214...c64c93c. Read the comment docs.

Isn't this essentially

toAppend.reduce((prev, curr) => prev.append(delim).append(curr), stmt)

Yeah that does the same thing but it's more difficult to read and prevents you from being able to chain additional append()s. Also, the for-loop will be more performant than a map(). curr will often be pretty long and/or complicated so it would be nice to be able to have the surrounding syntax as terse as possible. That may be another reason for moving this into the append() function instead of creating a new one.

What do you think?

Did you actually measure a performance difference? I doubt it has one (after all, you are IO-bound anyway for database queries).
Readability is a matter of taste, if I read reduce(), I instantly know what it does, while appendAll is a custom method where I need to "guess" its meaning (albeit pretty obvious).
I am reluctant to add helper methods (and the associated docs + tests) for features that can be solved functionally with vanilla JS... The biggest trait of this module is simplicity, and I don't want to bloat the API. Initially it didn't even have append, but that proved to be something that is non-trivial to do without a method.

Just wanted to chime in on this ancient PR. I agree shorthand functions can sometimes make readability worse, but in this case I think the pattern in question is so commonplace that the cost of having to read a new custom method and "guess" its meaning is less than the cost of having to parse this pattern out on every occurrence.

Isn't this essentially

toAppend.reduce((prev, curr) => prev.append(delim).append(curr), stmt)

It seems to me that in most cases you want the reduce-version adding the delimiter only starting from the second one and beyond

toAppend.reduce((prev, curr, index) =>
 (index > 0 ? prev.append(delim) : prev).append(curr), stmt)

@felixfbecker Hi there. I don't know if everything has been said on this topic. But I agree on the stated positions that an appendAll would be helpful.
https://www.npmjs.com/package/pg-template-tag solves this with a SQL.join function.