Phil Mayers wrote:
What will happen for queries which are *supposed* to return nothing in the normal case e.g.
%{sql:SELECT isbanned from bans where username='%{User-Name}'}
They still return nothing. The behavior is this: - queries which return empty strings are valid. - queries which fail are treated as empty strings when expanded because there's no "if/then/else" in %{...} - EXCEPT for %{%{foo}:-bar}. The failure of the first query means that the second one is used. The bug in rlm_sql was that SELECT returning no values was treated as an empty string, not as a failed query. So in an alternation, the empty string is a valid string, and the second part wasn't used. The use-case is selecting an IP address from a table: %{sql:SELECT ....} That should get you the IP, or *nothing* if the IP isn't in a table. Now let's say you want to return "255.255.255.255" if the IP isn't in the table. You do this: %{%{sql:SELECT ...}:-255.255.255.255} Previously, if there was no IP, you'd get '' as a result of the expansion. That's wrong. You now get '255.255.255.255', which is correct. Now, if you're dumb enough to put an empty string into the SQL table, you'll still get '' as the answer. But we can't help you there. The conditions in "if" statements behave the same, even after this change. if ("%{sql:SELECT ...}") { evaluates to '' if no results are returned. Because you haven't used alternation to say "if SELECT fails, give me another string". Alan DeKok.