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
Discussed a bit at length in #85, it is currently impossible to write queries that should contain a literal :. The named query parsing should be modified to allow for that by allowing the :: escape to mean a single : in the result query. This follows from the sql standard's '' to escape ' inside string literals.
This will be unlikely to have much impact on current uses of sqlx; there is no valid use of :: currently for named statements.
Reacted by Boris, Naosuke Ito, Colin, tmadge, Christopher Katsaras, Grzegorz Brzezinka, Dalton Stegner and Arvindh
In particular, I needed to use this in order to escape the colons in a named query that included a cast:
VALUES (:structmember ::::bytea)
I'm not sure if I would have seen the documentation before figuring this out, but I agree that having something in the illustrated guide, at least, would be useful. Of particular note is the space in between; sqlx's parser will complain otherwise, and postgres doesn't care.
Though
VALUES (CAST (:structmember AS bytea))
works without the need for any colons (if more verbosely), which I hadn't realized when I first encountered this problem.
Reacted by Alex Efros, Thomas, Naosuke Ito, Joshua Ma, tmadge, Muhammet Yazici, Taras Bunyk, Amir H. Meghdadian and Arvindh
Activity
oreqizer commentedon Jul 22, 2017
can this be documented, please? I've been battling two hours with this issue and haven't found it documented anywhere.
can create PR if yes
dhduvall commentedon Jun 5, 2019
In particular, I needed to use this in order to escape the colons in a named query that included a cast:
I'm not sure if I would have seen the documentation before figuring this out, but I agree that having something in the illustrated guide, at least, would be useful. Of particular note is the space in between;
sqlx's parser will complain otherwise, and postgres doesn't care.Though
works without the need for any colons (if more verbosely), which I hadn't realized when I first encountered this problem.
implement `::` as escaping for `:` in namedqueries, include test case…