@sandfox, @Suor: I tried doing .where(sql(...)) and it generated WHERE ... IS NULL. So I stepped through the code and found that SQL-Bricks supports two WHERE APIs: .where({key: value}) and .where(key, value). Since an object wasn't passed, sql-bricks thought we were attempting the 2nd API, and since there was no 2nd argument, sql-bricks interpreted it as a null.
In 47fc522, I added support for passing a single sql() literal. This made my test pass.
@Suor: In your example, you have parameters being passed to sql() as additional arguments.... this would be consistent with the other .where() uses, since they allow you to pass parameters -- I probably should add that too, since as it is you have to manually add the parameter values after SQL-Bricks generates the SQL string, but before it gets sent to postgres.
prust
commented
9 years ago
This is an attempt at addressing #60 (and, originally, https://github.com/Suor/sql-bricks-postgres/issues/2).
@sandfox, @Suor: I tried doing
.where(sql(...))and it generatedWHERE ... IS NULL. So I stepped through the code and found that SQL-Bricks supports two WHERE APIs:.where({key: value})and.where(key, value). Since an object wasn't passed, sql-bricks thought we were attempting the 2nd API, and since there was no 2nd argument, sql-bricks interpreted it as a null.In 47fc522, I added support for passing a single
sql()literal. This made my test pass.@Suor: In your example, you have parameters being passed to
sql()as additional arguments.... this would be consistent with the other.where()uses, since they allow you to pass parameters -- I probably should add that too, since as it is you have to manually add the parameter values after SQL-Bricks generates the SQL string, but before it gets sent to postgres.