SQLite

Changes On Branch flattener-column-names
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Changes In Branch flattener-column-names Excluding Merge-Ins

This is equivalent to a diff from bcec155e to 5df7f0e6

2017-07-31
20:06
TclKit batch tool updates for MSVC. Cherrypick of [bcec155e0d6c6b17] and [0c77935cf9949099]. (check-in: 96ff1675 user: mistachkin tags: branch-3.20)
2017-07-30
18:40
Correctly handle an "INTEGER PRIMARY KEY UNIQUE" column in a WITHOUT ROWID table. This is a fix for ticket [bc115541132dad136], a problem discovered by OSSFuzz. (check-in: 5216bfb7 user: drh tags: trunk)
2017-07-29
17:10
Merge latest trunk changes with this branch. (check-in: b42c8779 user: dan tags: server-process-edition)
16:01
Move the generation of output column names earlier, to right after name resolution and before query transformations such as flattening. This prevents the names from getting mangled by query transformations, and obviates hacks in the query flattener that attempt to work around the name mangling. The resulting code is smaller and faster and gives more consistent output. This is an alternative fix to ticket [de3403bf5ae5f72ed]. (check-in: 09834279 user: drh tags: early-column-names)
14:56
Use the subquery column name, not the original SQL statement text, as the added AS clause in the query flattener. (Closed-Leaf check-in: 5df7f0e6 user: drh tags: flattener-column-names)
03:33
In the query flattener, only add AS clauses to output columns of the outer query that are copied directly from the inner query. Formerly, all columns of the outer query received an AS clause if they did not have one already. This is a proposed fix for ticket [de3403bf5ae5f72]. (check-in: 439cc5c5 user: drh tags: flattener-column-names)
2017-07-28
22:22
Update Tcl version used by the TclKit batch tool for MSVC. (check-in: bcec155e user: mistachkin tags: trunk)
22:13
Fix harmless compiler warning. (check-in: 3286e1a0 user: mistachkin tags: trunk)

Changes to src/select.c.

3765
3766
3767
3768
3769
3770
3771
3772







































3773
3774
3775
3776
3777
3778
3779
3780
3781
3782
3783
3784
3785
3786
3787
3788
3789
3790
3791
3792
3793
3794
3795
3796
3797
3798
3799
      sqlite3IdListDelete(db, pSrc->a[i+iFrom].pUsing);
      assert( pSrc->a[i+iFrom].fg.isTabFunc==0 );
      pSrc->a[i+iFrom] = pSubSrc->a[i];
      iNewParent = pSubSrc->a[i].iCursor;
      memset(&pSubSrc->a[i], 0, sizeof(pSubSrc->a[i]));
    }
    pSrc->a[iFrom].fg.jointype = jointype;
  







































    /* Now begin substituting subquery result set expressions for 
    ** references to the iParent in the outer query.
    ** 
    ** Example:
    **
    **   SELECT a+5, b*10 FROM (SELECT x*3 AS a, y+10 AS b FROM t1) WHERE a>b;
    **   \                     \_____________ subquery __________/          /
    **    \_____________________ outer query ______________________________/
    **
    ** We look at every expression in the outer query and every place we see
    ** "a" we substitute "x*3" and every place we see "b" we substitute "y+10".
    */
    pList = pParent->pEList;
    for(i=0; i<pList->nExpr; i++){
      if( pList->a[i].zName==0 ){
        char *zName = sqlite3DbStrDup(db, pList->a[i].zSpan);
        sqlite3Dequote(zName);
        pList->a[i].zName = zName;
      }
    }
    if( pSub->pOrderBy ){
      /* At this point, any non-zero iOrderByCol values indicate that the
      ** ORDER BY column expression is identical to the iOrderByCol'th
      ** expression returned by SELECT statement pSub. Since these values
      ** do not necessarily correspond to columns in SELECT statement pParent,
      ** zero them before transfering the ORDER BY clause.
      **







|
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>












<
<
<
<
<
<
<
<







3765
3766
3767
3768
3769
3770
3771
3772
3773
3774
3775
3776
3777
3778
3779
3780
3781
3782
3783
3784
3785
3786
3787
3788
3789
3790
3791
3792
3793
3794
3795
3796
3797
3798
3799
3800
3801
3802
3803
3804
3805
3806
3807
3808
3809
3810
3811
3812
3813
3814
3815
3816
3817
3818
3819
3820
3821
3822
3823








3824
3825
3826
3827
3828
3829
3830
      sqlite3IdListDelete(db, pSrc->a[i+iFrom].pUsing);
      assert( pSrc->a[i+iFrom].fg.isTabFunc==0 );
      pSrc->a[i+iFrom] = pSubSrc->a[i];
      iNewParent = pSubSrc->a[i].iCursor;
      memset(&pSubSrc->a[i], 0, sizeof(pSubSrc->a[i]));
    }
    pSrc->a[iFrom].fg.jointype = jointype;

    /* For every result column in the outer query that does not have an AS
    ** clause, if that column is a reference to an output column from the
    ** inner query, then preserve the name of the column by adding an AS clause.
    ** This prevents the outer query column from taking on a name derived
    ** from inner query column name.
    **
    ** Example:
    **     CREATE TABLE t1(a,b);
    **     CREATE VIEW v1(x,y) AS SELECT a,b FROM t1;
    **     SELECT x,y FROM v1;
    **
    ** The inner "v1" subquery will get flattened into the outer query.  After
    ** flattening, the outer query becomes:  "SELECT a,b FROM t1".  But the
    ** new query gives column names of "a" and "b", not the "x" and "y" that
    ** the programmer expected.  This step adds AS clauses so that the
    ** flattened query becomes:  "SELECT a AS x, b AS y FROM t1".
    **
    ** Update on 2017-07-29:  The current implementation only adds AS clauses
    ** to outer query result columns that are substituted directly for
    ** columns of the inner query.  Formerly, all result columns in the outer
    ** query got new AS clauses if they didn't have them all ready.  Also,
    ** the name of the AS clause is taken from the result column name of
    ** the inner query.  Formerly, the name was a copy of the text of the
    ** original SQL statement that specified the column.
    */
    pList = pParent->pEList;
    for(i=0; i<pList->nExpr; i++){
      Expr *p;
      if( pList->a[i].zName==0
       && (p = pList->a[i].pExpr)->op==TK_COLUMN
       && p->iTable==iParent
       && p->iColumn>=0
       && ALWAYS(p->pTab!=0)
      ){
        char *zName = sqlite3DbStrDup(db, p->pTab->aCol[p->iColumn].zName);
        pList->a[i].zName = zName;
      }
    }

    /* Now begin substituting subquery result set expressions for 
    ** references to the iParent in the outer query.
    ** 
    ** Example:
    **
    **   SELECT a+5, b*10 FROM (SELECT x*3 AS a, y+10 AS b FROM t1) WHERE a>b;
    **   \                     \_____________ subquery __________/          /
    **    \_____________________ outer query ______________________________/
    **
    ** We look at every expression in the outer query and every place we see
    ** "a" we substitute "x*3" and every place we see "b" we substitute "y+10".
    */








    if( pSub->pOrderBy ){
      /* At this point, any non-zero iOrderByCol values indicate that the
      ** ORDER BY column expression is identical to the iOrderByCol'th
      ** expression returned by SELECT statement pSub. Since these values
      ** do not necessarily correspond to columns in SELECT statement pParent,
      ** zero them before transfering the ORDER BY clause.
      **