On Tue, Apr 9, 2019 at 9:41 AM Richard Hipp <d...@sqlite.org> wrote: > On 4/9/19, Dominique Devienne <ddevie...@gmail.com> wrote: > >> > >> It defines the table and view: > >> CREATE TABLE t1(a INT, b TEXT, c REAL); > >> CREATE VIEW v1(x,y,z) AS SELECT b, a+c, 42 FROM t1 WHERE b!=11; > >> > >> It then states "The affinity of the v1.x column will be the same as the > >> affinity of t1.b (INTEGER), since v1.x maps directly into t1.b.". > >> > >> However column t1.b is TEXT, not INTEGER. > >> > > > > How to do determine that exactly? Via SQL? Debugging? > > If you compile with -DSQLITE_DEBUG, then there is a new undocumented > function affinity(). After inserting a row into table t1: >
Cool! Thanks for the heads up. But why debug only? It's as useful as typeof() IMHO. Obviously affinity-related-code is compiled-in in non-debug build, so I don't see any down side of unconditionally adding a function that if not explicitly used as zero runtime overhead, no? While SQLITE_DEBUG itself likely adds overhead. Would be really useful for troubleshooting and teaching to always have it. My $0.02. --DD _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
