-
Notifications
You must be signed in to change notification settings - Fork 64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
glue_sql converts length-0 vectors to NULL in asterisk-expansion #272
Comments
x <- character(0)
glue::glue_sql("({x*})")
#> <SQL> (NULL) Created on 2023-01-25 with reprex v2.0.2 |
* Collapse empty vectors to empty string Fixes #272 * Fix typo --------- Co-authored-by: Jennifer (Jenny) Bryan <jenny.f.bryan@gmail.com>
Post upgrade to glue version 1.7.0, we encountered a breaking change in how glue_sql handles empty vectors. Previously, empty vectors were collapsed to "NULL" in SQL queries, which was functional for our use case. However, since the update, empty vectors are now collapsed to an empty string, resulting in syntax errors in SQL queries with IN clauses. This change impacts all database queries where we dynamically generate IN clauses based on possibly empty vectors. The new behavior leads to malformed SQL queries and runtime errors, significantly affecting our data retrieval processes. Could we consider reintroducing the previous behavior of collapsing empty vectors to "NULL" in SQL queries, or provide an option to toggle between the two behaviors? This would allow for backward compatibility and flexibility for different use cases. We've implemented a workaround where we manually check for empty vectors and adjust the SQL query accordingly. However, this adds complexity and boilerplate code, which was elegantly handled by glue_sql in previous versions. |
@jasonheffnerpsu can you please file an new issue instead of commenting on a closed issue? |
Apologies .. I don't raise issues often and don't know process |
Sorry, did the same (commenting on a closed issue). I will report my use case at #318. |
When used as part of an SQL expression, this can happen:
... which has different semantics (in most SQL variants) than what I believe most users likely are intending when
x
is empty:# <SQL> select foo from bar where baz in () <-- the _intended_ SQL, I think.
I've confirmed this also happens with DB object identified expansion, too, i.e.:
The text was updated successfully, but these errors were encountered: