Reject user from SQL-DB

[JB]

Phil Mayers (29.02.2008):
> JB wrote:
>> Phil Mayers:
>>> JB wrote:
>>>> I'm sorry, I have to ask again. Have you found a way to let the  
>>>> reply query know that the user has already been rejected in the  
>>>> check-query? I'm trying to avoid executing the same queries twice  
>>>> and also to avoid using temporary tables.
>>>
>>> I thought I'd answered this?
>>> """What you could do is place a local attribute in the check  
>>> items, then copy it to the reply items in an unlang section..."""
>>> Which you said worked in a later email
>> Sorry if I haven't made myself clear enough. These were two  
>> different things.
>> On the on hand, I wanted to return a Reply-Message to the user  
>> which is set in one of the two queries, which works fine the way  
>> you proposed.
>> On the other hand, I wanted to avoid executing unnecessary sub- 
>> queries in the reply query (a stored procedure in my case), or the  
>> reply query itself, if the user has already been rejected in the  
>> check query. It seems that the reply query is always executed. And  
>> if I call the stored procedure with attributes like "%{control:Auth- 
>> Type}" or "%{control:My-Reply}", they don't get resolved although  
>> they're set in the first query.
>> In pseudo-code:
>> Check query: reject user because of reason 'xyz', set My-Attr to  
>> 'xyz'. [works]
>> If rejected, don't call reply query (or at least call reply query  
>> with resolved attributes to avoid unnecessary sub-queries) [doesn't  
>> work]
>> If rejected copy My-Attr to Reply-Message [works]
>
> Ah I see.
>
> No, the "sql" module doesn't work that way - if *any* check pairs  
> are returned (and match) the reply query is run, but the  
> pairxlatmove() is done *after* the reply query is done - i.e. it  
> does this:
>
> check_items = sql(check_query)
> if paircompare(request, check_items):
>  reply_items = sql(reply_query)
>  pairxlatmove(request->reply_items, reply_items)
>  pairxlatmove(request->check_items, check_items)
>
> The only way you could change this would be with source-code patches  
> or use rlm_perl/python to do the logic you want.
>
> Arguably the check items pairxlatmove() should be before the reply  
> query, but then if the xlat of the reply query or reply query itself  
> fail, you'd have added check items without corresponding reply items  
> (but the module would have returned a fail error code, so it's  
> probably not a big deal)
>
> You could move the check items pairxlatmove() call - it's line 669  
> in src/modules/rlm_sql/rlm_sql.c in my copy of 2.0.0, and would need  
> to move to just above line 651 i.e. the radius_xlat of the reply  
> query.

Thanks a lot, your help really is appreciated! I'll try that.
Do you think there is a chance that this patch would make it into a  
final release? Could this break current installations in any way?

JB