Adding basic support for IF conditions in SELECT clause

[tomershay]

Adding support for IF conditions in SELECT clause.
Example: SELECT IF(a = 5, 200, 404), columnA, columnB from table.
Supporting different condition types for the first argument - LIKE, AND / OR, etc.

[coveralls]

Coverage increased (+0.03%) to 87.074% when pulling e2bd0fe on sh-tomer:support_if_conditions into b1abc6f on JSQLParser:master.

[coveralls]

Coverage increased (+0.03%) to 87.074% when pulling 3a0fe5d on sh-tomer:support_if_conditions into b1abc6f on JSQLParser:master.

[wumpz]

Thx for splitting. It makes reviewing much easier. Wouldn't it be a much more general approach to allow conditions as parameters for functions? Then the IfExpression class would be obsolete.

[tomershay]

@wumpz, sure, I'm happy to contribute to this great project as much as I can.
Can you please elaborate on your suggestion? I'm not sure I fully understood.
IF conditions are not always related to function calls, for example:
SELECT IF(file_deleted=1, 'yes', 'no') as deleted_str, another_col from table1;

If you were referring to the option of considering the "IF" as a function with 2 to 3 parameters, then I'm not sure this will be the best path here, as it might cause a big pain in the future, as it's not really a function.

Also, having a dedicated class (IfExpression) allows to 'visit' the instances easily, same as with CASE / WHEN conditions and other special structures.

Looking forward to hearing your thoughts.

[wumpz]

Looking at http://sqlfiddle.com/#!17/cc4c9/1/0 you see, that using e.g. Postgresql you are able to use a relation as a normal parameter: func(col='A'). So allowing such parameters the function if is reduced to a simple function call.

[tomershay]

Can't see which function call are you referring to. The query in that fiddle is:
select col1='A' from table1
If it's possible to send a condition as a parameter of a function call in PostgreSQL, doesn't it mean that we need to make sure that IfExpression can be a parameter of a function call? Isn't that the same as having a way to send LongValue as a function parameter?
Still not sure I understand the advantage of tying if conditions and function calls together.
Thanks for providing clarifications, I appreciate it.

[wumpz]

Sorry for beeing unclear. In Postgresql it would be perfectly valid to write a function that processes myfunc(mycol = 'A'), indeed every function with a boolean parameter could receive this as a parameter. This is a whole class of functions (including this kind of parameter) JSqlParser is not able to parse.
Therefore going the general approach in JSqlParser to allow every function to get relations as parameters would include the if function as well.

Hope that was clearer.

[tomershay]

Thanks for the clarification.
I'm not sure I would tie both cases together though. As far as I can see, in MySQL, you can't write that kind of condition in a select clause (it requires all 3 parameters to exist). On the other hand, in PostgreSQL you can send the IF condition as a parameter, while it only has the condition inside (without the then / else parts).
Therefore, I see those two as different structures that probably should be handled differently.
How would you suggest to approach that from your experience with JSqlParser?

[tomershay]

@wumpz, did you get a chance to look into my last comment? Will be glad to see this change pulled in case you agree.

[wumpz]

@sh-tomer If you referring about syntactical correctness for one database, I think you are right. Nevertheless I see JSqlParser as a parser and not a validator of specific database constructs. So you could write using Postgresql a function if with one parameter and could go with this relational parameter if(col='A'). If you implement if as IfExpression, than there are problem arising parsing the also correct Postgresql variant. Or did I missunderstand you?