compileNamedQuery variable inside a string

[vibbix]

While using sqlx's namedquery's i realized that the library believes that all instances of the colon are somehow are named variables, even if there inside a string. In my case with postgres, i had a interval notation as a string that was typed as '01:30:30' that cause the error "unexpected : while reading named param at [LOCATION]". I've been trying to fix the error most of the day, and my solution is having a bool flip while its reading a string to continue reading from it, with a sanity check to check if the comma is being escaped or not.

try running this code for example

var qs = SELECT * FROM testtable WHERE timeposted BETWEEN (now() AT TIME ZONE 'utc') AND (now() AT TIME ZONE 'utc') - interval '01:30:00') AND name = ''this is a test'' and id = :id

previously, this would fail with said error, but now it works! I havent had a chance to add any unit test in, but you can use my scenario above in named_test.go

[jmoiron]

The reason that the current treatment of ":" is kinda dumb is because that's the most straightforward way to reason about it. This patch fails on RDBMS where strings can be quoted by other characters than ' or in RDBMS (like mysql) where string literals can use escapes other than '' for a literal ', etc:

mysql> SELECT 'valid mysql string \' still continues, but now 1:30 fails';

For the general purpose, parsing these strings is too difficult and the : character only becomes a problem in data that can be parameterized. I've contemplated allowing queries to use :: to escape a literal :, since that would be straightforward behavior. I'm not sure why I never did it though.

What are your thoughts?

[vibbix]

I'm currently at work, and I just realized that the usage of ':''s also
broke typecasting in postgres, which I didn't realize until this morning. I
won't be home until later tonight, so I can test my theory on how to fix
that.

On Wed, Jul 15, 2015, 11:56 PM Jason Moiron notifications@github.com
wrote:

The reason that the current treatment of ":" is kinda dumb is because
that's the most straightforward way to reason about it. This patch fails on
RDBMS where strings can be quoted by other characters than ' or in RDBMS
(like mysql https://dev.mysql.com/doc/refman/5.0/en/string-literals.html)
where string literals can use escapes other than '' for a literal ', etc:

mysql> SELECT 'valid mysql string ' still continues, but now 1:30 fails';

For the general purpose, parsing these strings is too difficult and the :
character only becomes a problem in data that can be parameterized. I've
contemplated allowing queries to use :: to escape a literal :, since that
would be straightforward behavior. I'm not sure why I never did it though.

What are your thoughts?

—
Reply to this email directly or view it on GitHub
#151 (comment).

[vibbix]

In my opinion using colons as an escape character will force others to rewrite some of there code to work with the library. I just tried to run that mysql query through the patched code and it ran fine, i already added a check for backslashes to prevent that type of issue. I've been working later than usual so i haven't had time to really work out a solution recently, which i'm gonna start now.