SQLite

Check-in [0c38dde454]
Login

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

Overview
Comment:New test cases for column name generation interacting with the query flattener.
Downloads: Tarball | ZIP archive
Timelines: family | ancestors | descendants | both | early-column-names
Files: files | file ages | folders
SHA3-256: 0c38dde4543d6183a6ab0b7b3b75819f56c47704756a2426d54d3f20468d78d8
User & Date: drh 2017-07-29 17:02:22.699
References
2017-07-31
17:40
More consistent column names. Cherry-pick of [09834279] and [0c38dde45] as a fix for ticket [de3403bf5ae]. (check-in: be0e24a029 user: drh tags: branch-3.20)
Context
2017-07-31
17:40
More consistent column names. Cherry-pick of [09834279] and [0c38dde45] as a fix for ticket [de3403bf5ae]. (check-in: be0e24a029 user: drh tags: branch-3.20)
16:42
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. Fix to ticket [de3403bf5ae5f72ed]. (check-in: ade7ddf199 user: drh tags: trunk)
2017-07-29
17:02
New test cases for column name generation interacting with the query flattener. (Closed-Leaf check-in: 0c38dde454 user: drh tags: early-column-names)
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: 09834279ae user: drh tags: early-column-names)
Changes
Side-by-Side Diff Ignore Whitespace Patch
Changes to test/colname.test.
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
9
10
11
12
13
14
15

16
17
18
19
20
21
22







-







#
#***********************************************************************
# This file implements regression tests for SQLite library. 
#
# The focus of this file is testing how SQLite generates the names
# of columns in a result set.
#
# $Id: colname.test,v 1.7 2009/06/02 15:47:38 drh Exp $

set testdir [file dirname $argv0]
source $testdir/tester.tcl

# Rules (applied in order):
#
# (1) If there is an AS clause, use it.
321
322
323
324
325
326
327
328






















































329
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382








+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+

do_test colname-8.1 {
  db eval {
    CREATE TABLE "t3893"("x");
    INSERT INTO t3893 VALUES(123);
    SELECT "y"."x" FROM (SELECT "x" FROM "t3893") AS "y";
  }
} {123}

# 2017-07-29: Interaction between column naming and query flattening.
# For years now, the query flattener has inserted AS clauses on the
# outer query that were the original SQL text of the column.  This caused
# column-name shifts when the query flattener was enhanced, breaking
# legacy applications.  See https://sqlite.org/src/info/41c27bc0ff1d3135
# for details.
#
# To fix this, the column naming logic was moved ahead of the query
# flattener so that column names are assigned before the query flattener
# runs.
#
db close
sqlite3 db :memory:
do_test colname-9.100 {
  db eval {
    CREATE TABLE t1(a,b);
    INSERT INTO t1 VALUES(1,2);
    CREATE VIEW v1(x,y) AS SELECT a,b FROM t1;
  }
  execsql2 {SELECT v1.x, (Y) FROM v1}
  # Prior to the fix, this would return:  "v1.x 1 (Y) 2"
} {x 1 y 2}
do_test colname-9.110 {
  execsql2 {SELECT * FROM v1}
} {x 1 y 2}
do_test colname-9.120 {
  db eval {
    CREATE VIEW v2(x,y) AS SELECT a,b FROM t1 LIMIT 10;
  }
  execsql2 {SELECT * FROM v2 WHERE 1}
} {x 1 y 2}
do_test colname-9.130 {
  execsql2 {SELECT v2.x, [v2].[y] FROM v2 WHERE 1}
} {x 1 y 2}
do_test colname-9.140 {
  execsql2 {SELECT +x, +y FROM v2 WHERE 1}
} {+x 1 +y 2}

do_test colname-9.200 {
  db eval {
    CREATE TABLE t2(c,d);
    INSERT INTO t2 VALUES(3,4);
    CREATE VIEW v3 AS SELECT c AS a, d AS b FROM t2;
  }
  execsql2 {SELECT t1.a, v3.a AS n FROM t1 LEFT JOIN v3}
} {a 1 n 3}
do_test colname-9.211 {
  execsql2 {SELECT t1.a AS n, v3.a FROM t1 JOIN v3}
} {n 1 a 3}
do_test colname-9.210 {
  execsql2 {SELECT t1.a, v3.a AS n FROM t1 JOIN v3}
} {a 1 n 3}


finish_test