The general case of a data type definition is an arbitrarily complex predicate expression whose parts vary on the base type and other factors. Given this, if component details of type definitions were split out into their own table_info() columns, you'd have a large number of columns where most are inapplicable in any given case, eg some only apply to strings, some only to numbers, etc. And so, just expressing the type definition as a SQL fragment like table_info() currently does provides a compact generic representation with all the details, same as in CREATE TABLE. -- Darren Duncan
On 2016-04-22 6:09 AM, Igor Korot wrote: > Hi, ALL, > > [code] > SQLite version 3.9.2 2015-11-02 18:31:45 > Enter ".help" for usage hints. > sqlite> PRAGMA table_info(league); > sqlite> PRAGMA table_info(leagues); > 0|id|integer|0||1 > 1|name|varchar(100)|0||0 > 2|drafttype|integer(1)|0||0 > 3|scoringtype|integer(1)|0||0 > 4|roundvalues|integer(1)|0||0 > 5|leaguetype|char(5)|0||0 > 6|salary|integer|0||0 > 7|benchplayers|integer(1)|0||0 > sqlite> > [/code] > > The field type is set to be "varchar(100)" for the name field. > Wouldn't it be more logical to have it as "varchar" and have another field > for data size? > > Thank you. > > P.S.: I don't know how most databases interpret this, I know ODBC does it > this way....
