On Wed, Apr 6, 2016 at 1:37 PM, Niko Tyni <nt...@debian.org> wrote: > On Wed, Apr 06, 2016 at 01:07:17PM +0200, László Böszörményi wrote: >> It seems it'll stay. Please read the opinion of the main SQLite3 >> developer[1]: >> "This could easily be considered a bug fix rather than a regression." >> There are examples in his mail which demonstrate why a type of view is >> unambiguous and should not be depend on. Hence they chose to return an >> empty string for these queries. > > OTOH there's this trunk commit from yesterday: > http://www.sqlite.org/src/info/fb555c3c2af7f5e6 > > which looks like it's trying to restore the older behaviour? Nope, it seems to implement the proposal I've mentioned in my last email[1] just like commit log states: "Carry table column types through into VIEW definitions, where possible." If you read the diff you mentioned, it seems to confirm this. See the right side addition (in green) of src/build.c: In case 'pTable->pCheck' (maybe an abbreviation of parameter check) returns true, then the parameters used as arguments for the VIEW (ie, it's in the form: "CREATE VIEW name(arglist) AS"): 'The names of the columns in the table are taken from arglist which is stored in pTable->pCheck. The pCheck field normally holds CHECK constraints on an ordinary table, but for a VIEW it holds the list of column names.' Then it parses the list with sqlite3ColumnsFromExprList() and if it doesn't have errors (pParse->nErr==0) it adds the types with sqlite3SelectAddColumnTypeAndCollation().
If the mentioned check returns false then it seems no type added there. But later it's checked for a type (maybe in case of simple columns and no action defined columns): zType = columnType() and if( zType... ). Then if the check succeeds, the type gets used: memcpy(&pCol->zName[n+1], zType,...) (copying the type) pCol->colFlags |= COLFLAG_HASTYPE; (flagging that it has a known type) But I don't know the SQLite3 source, just read what it seems to be. Laszlo/GCS [1] http://article.gmane.org/gmane.comp.db.sqlite.general/100898
