Commit report for master branch

[Alan DeKok]

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.