You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
In our sql files we make use of placeholders (?0) so that these can be replaced dynamically when read by bun. When ran through sqlfmt it adds a space between the ? and the 0. The following statement "time" = ?0 becomes "time" = ? 0 which makes it invalid.
This is not a feature of standard SQL but I would expect the formatter to leave these statements as is. My assumption is that the ? is read as a statement of it's own, but I can't locate the source of it.
To Reproduce
See example above
Expected behavior
I would expect no formatting to happen between these characters.
Additional context
sqlfmt, version 0.14.3
The text was updated successfully, but these errors were encountered:
Similar to psycopg placeholders #198 and pg variables/placeholders a5d7dd0
Looks like bun's syntax is r"\?\d*", including the bare ?, which collides with the use of ? as an operator in some dialects (we're parsing ? as an operator now). e.g., postgres: jsonb ? text → boolean
But I think we can easily support r"\?\d+" in the other_identifiers rule without any bad side-effects. Change would be here:
Describe the bug
In our sql files we make use of placeholders (
?0
) so that these can be replaced dynamically when read by bun. When ran throughsqlfmt
it adds a space between the?
and the0
. The following statement"time" = ?0
becomes"time" = ? 0
which makes it invalid.This is not a feature of standard SQL but I would expect the formatter to leave these statements as is. My assumption is that the
?
is read as a statement of it's own, but I can't locate the source of it.To Reproduce
See example above
Expected behavior
I would expect no formatting to happen between these characters.
Additional context
sqlfmt, version 0.14.3
The text was updated successfully, but these errors were encountered: