Re: scope of alias variables

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.

 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 12:06:44 UTC