Postgres follows standards for operator `||`
Closed this issue · 3 comments
While we tried to find a solution for #97, I've found that cortex assume that all db engines interpret the || as OR function.
Line 2585 in 364caaa
As per the Postgres wiki, Mysql "violates database standards".
MySQL uses C-language operators for logic (i.e. 'foo' || 'bar' means 'foo' OR 'bar', 'foo' && 'bar' means 'foo' and 'bar'). This might be marginally helpful for C programmers, but violates database standards and rules in a significant way. PostgreSQL, following the standard, uses || for string concatenation ('foo' || 'bar' = 'foobar').
https://wiki.postgresql.org/wiki/Things_to_find_out_about_when_moving_from_MySQL_to_PostgreSQL
Mysql
Postgres
This substitution should be dependent on the underlying db engine at least for Postgres.
Oh well.. could it be worse?
I've checked sqlite and sql server and they do not use || for or, but also for concatination. The code is there to unify some behaviours and expectations for queries. How would have thought that that statements means concat? Me not, as I wrote that. The problem is when i remove that now, it would break compatibility, since i do not know if that was something intentionally used in any project.. and since the "normal" syntax for Jig, or MySQL would recognize it as OR, I'm not sure what would be the option here. Maybe make that array configurable as workaround?!
it would break compatibility, since i do not know if that was something intentionally used in any project
I understand, such change should be taken with care. Should choose between making it a deprecation and fix it for engines we know use it as CONCAT() vs adding an option to enable "standards"…
Should be fixed now. I'll remove it in a future version.