Re: scope of alias variables

Andy Seaborne wrote:
> 
> 
> On 13/11/2009 04:53, Lee Feigenbaum wrote:
>>> > **  ISSUE-39: Variable scope of alias variables
>>> >
>>> > Consensus that variables on the right-hand side of "AS" (alias
>>> variables) are not in scope for the rest of the query (including
>>> projected expressions), but not including outer queries of course.
>>>
>>> Disagree - this is an unnecessary restriction and results in needing
>>> addition nesting of SELECTs just to reuse an expression.
>>
>> What's an example of this? Does this only apply when an expression has
>> side-effects or does not evaluate the same when invoked twice?
> 
> See the discussion around Holger's example - he uses the result of one 
> expression in another
> 
> In the SELECT case where the aggregate is in SELECT clause:
> 
> SELECT (count(*) AS ?C) , (?Num/?C)
> 
> It should also ways be possible to replace ?C by the expression used 
> originally but as the expression becomes more complicated it becomes a 
> nuisence.
> 
> Nesting SELECTs has the effect:
> 
> SELECT (?Num/?C)
>   SELECT (count(*) AS ?C)
> 
> so we can define the scope in the same way - left-to-right across the 
> list of expressions - but it makes the feature non-critical.
> 
>> This was driven in part, I believe, by what existing implementations did
>> that were discussed at the F2F.
> 
> ARQ does it
> 
> 'SELECT (1 as ?A) (?A+2 AS ?B) {}'
> 
> ---------
> | A | B |
> =========
> | 1 | 3 |
> ---------
> 
> It didn't occur to me to not allow it but maybe that's the way the 
> implementation works.  There's a step which does one AS so multiple ones 
> are just a sequence of these.
> 
>> In an alternate design, what is the scope of alias variables? Where
>> can/can't they be used?
> 
> A variable's scope across the select expression begins after the AS that 
> mentions it.
> 
> SELECT (?A+1 as ?A) {}
> 
> The ?A in ?A+1 is out-of-scope.

How does it work if the alias variable is used in the query pattern?

Lee

>     Andy
> 
>>
>> Lee
>>
>> ______________________________________________________________________
>> This email has been scanned by the MessageLabs Email Security System.
>> For more information please visit http://www.messagelabs.com/email
>> ______________________________________________________________________
>

Received on Friday, 13 November 2009 14:11:54 UTC