f) There are exactly 2 documented functions in your code. Did you not read their documentation???
See https://sqlite.org/c3ref/column_blob.html " After a type conversion, the result of calling sqlite3_column_type() is undefined, though harmless. Future versions of SQLite may change the behavior of sqlite3_column_type() following a type conversion." b) Breaking encapsulation includes referencing internal .h files in your own code. You should be using sqlite3.h *only* You do realise that declared types are not enforced in SQLite? If somehow a real with a non-integer value got inserted into an integer field, the type of the returned value would still be real, but you would be expecting integer. And silently reading the bits of the double value as an integer, which would probalby cause a practically untetectable error. c) There is no guarantee that the internal fields referring to a previous state of a Mem structure are preserved across conversions. I do hope you are statically linking your modified SQLite code to your application and not installing it as a shared image. In the latter case, some unsuspecting application might inadvertently stumble across your version of the interface, which no longer conforms to the published interface, and cause failures there. That would probably cause some really rave reviews. "I just installed XXX on my phone and it died" is not a viable recommendation. -----Ursprüngliche Nachricht----- Von: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] Im Auftrag von Barone Ashura Gesendet: Dienstag, 30. Juli 2019 14:51 An: SQLite mailing list <sqlite-users@mailinglists.sqlite.org> Betreff: Re: [sqlite] [EXTERNAL] sqlite3_exec without ubiqitous text conversions 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 ___________________________________________ Gunter Hick | Software Engineer | Scientific Games International GmbH | Klitschgasse 2-4, A-1130 Vienna | FN 157284 a, HG Wien, DVR: 0430013 | (O) +43 1 80100 - 0 May be privileged. May be confidential. Please delete if not the addressee. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
