Thanks for the response you gave me the kind of answer I was looking for.
a) you are circumventing the intended interface > I know, I am aware, and that is exactly what I wanted to do; I Wrote to the mailing list to decide if I will really do it or not > b) you are breaking encapsulation, because columnMem returns a pointer to > an internal type, which is useless to you, unless you have made public all > the SQLite internals > The change is not indended for distribution, it is going to be a change in our codebase. The Internal type goes down to a struct having a union at its base address, such union contains either a double or a int64 value, for REAL and INTEGER values respectively (unless I wrongly assume that the internal representation of Mem pointer, is, under specific circumstances (which I havent yet stumpled upon in testing), inconstistent with the type reported by sqlite3_column_type. This means that I have no need to make all SQLite internals public. As I said I already keep track of the base type of each column in my sqlite database; in all the testing performed, I never failed to identify the correct datatype for the pointer. I cannot exclude that there are situation where I will fail, and that is why I posted here. c) you are assuming that type conversion of a Mem type will conserve the > original fields > This is the real 'unknown' to me issue, could you please elaborate a little more? Which are the original fields you are referring to? Which type conversions of a mem type are you referring to? > d) you are duplicating work by calling sqlite3_column_text() twice, unless > the type is numerical > e) you are duplicating work by calling sqlite3_column_type() twice, > instead of using the value returned from the first call > True, will be fixed... I focused too much on trying out the consistency of the change and the lack of regressions. > f) you are using the result of a function call that is documented to be > undefined in the exact context you are using it in > Which is the function you are referring to? which context are you referring to? > IMHO, you would be much better off attempting to master the official > SQLite API. > Opinion acknowledged and taken in serious consideration, Nothing (except eventual development time constraints) prevents me from embracing your advice. Thanks again _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
