feat: sql.join
closes #807, to add sql.join:
let dynamicFilters = [
sql`somecol = ${somevalue}`,
sql`col2 = ${v2}`
];
const dynamicColumns = [sql('somecol'), sql('col2')];
await sql`
select ${sql.join(sql`, `, dynamicColumns)} from t
where ${sql.join(sql` and `, dynamicFilters)};
`;
i'm not 100% sure the types are right, and I couldn't get the tests to run, so those probably need some work
if you have a weird workaround you can try this fix in your own projects
npm i github:danielfgray/postgres.js
@Destreyf @davepar your feedback would be appreciated!
I also really want to enable currying to allow things like
const and = sql.join(sql` and `)
and(sql`...`, ...fragments)
which could be as simple as
- function join(sep, xs) {
+ function join(sep, ...xs) {
+ if (!xs) return join.bind(null, sep)
return xs.flatMap((x, i) => {
but this would probably also need further bike-shedding
I also wonder if the API could be further improved to simply allow
const and = sql.join` and `
const params = and(f1, f2, f3)
// would work the same as
const params = sql.join` and `(f1, f2, f3)
I'm not sure that postgres.js goals are to be a whole query builder, but it seems like we can add a lot of expressivity with a few tweaks to a simple feature
but currying is likely to increase the complexity of the TS types and perhaps make the API more complex and difficult to document :balance_scale:
neat feature, hope this makes it in +rep
I agree though that it should not be called "join" to avoid confusion with SQL's JOIN statements. In my opinion, "sql.concat" is a better choice.
solid addition 👍
I agree though that it should not be called "join" to avoid confusion with SQL's JOIN statements. In my opinion, "sql.concat" is a better choice.
I've gone back and forth on this in my head, and while there's definitely potential for ambiguity, join here is behaving the same as it does on arrays
It would be even more surprising behavior to me to have something called concat behaving as Array#join, and if a user is confused on what sql.join does the docs would explain. I also think actually seeing the code in context would pretty well indicate it has nothing to do with the SQL clause
So all this is to say, semantically, I think join is the best name for this feature
What's required to get this in? I also struggled discovering how to do this expecting the library to provide a mechanism.
What's required to get this in? I also struggled discovering how to do this expecting the library to provide a mechanism.
getting the tests to pass is probably the main blocker
I'd like the api to be like this:
sql` and `.join(...)
I consider this PR a success then, even if my implementation/API aren't used
May I ask @DanielFGray why you closed your PR? I had hopes that after your recent change to the API to match @porsager's request it might get merged soon..
May I ask why you closed your PR?
@dhardtke the work in the PR itself is pretty trivial, and I don't currently have the time/energy to work on refactoring it, so I'll step aside rather than impede progress.