On Thu, Feb 6, 2020 at 9:32 AM Hick Gunter <h...@scigames.at> wrote: > >Of course, it may be that the writer of the VTable should know what they are > >doing and generate a VTable definition that is consistent with how their > >cursor methods return data, however ... this will omit the OP_Affinity if no > >>column type was specified when the VTable was defined and most of the > >VTable declarations in the existing code that I looked at do not specify > >column affinities in the declarations. > > Very nice. but detrimental for our use case. Please refrain from adding this > tot he distribution by default. > We are almost exclusively using virtual tables to allow queries against our > internal data sources, which are C language structs and thus strictly typed. > The column affinities provided by the VTab implementations are used for > documentation purposes and the xColumn methods always return the same type > (calling the "wrong" sqlite3_result function is considered a programming > error). Coercing the returned value to the same type would be just a waste of > memory and CPU cycles.
+1. I fear what it would do to our app, also making extensive use of vtables. Like Gunter mentions, the type is there more for documentation, I'm unsure "what havoc this could wreak". Note that our vtables are all read-only, if that matters here. It's unclear to me if the above applies to writes only, or also applies to reads. If to writes only, then I don't care much at the moment, although I might in the future, and would likely prefer seeing the raw value in my code, than the result of affinity-coercion. --DD _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
