I really wish to keep the argument polite and constructive, so please dont get me wrong if I reply, I just want to understand what you are referring to, realize and evaluate which is the best way to go for me, not for the sqlite library, that's why I writing to the sqlite library.
Il giorno mar 30 lug 2019 alle ore 15:50 Hick Gunter <h...@scigames.at> ha scritto: > 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." > which type conversion are you referring to? the second one erroneously called in the example code? I do understand the 'type conversion' to be one of the six functions listed in the page you linked (which was read). The statement before the one you quoted specifically says: "The return value of sqlite3_column_type() can be used to decide which of the first six interface should be used to extract the column value". Isnt this exactly what I want to be doing? Read the column type from the statement, according to the return value call the relevant extraction function. The documentation describes 'automatic conversions' being performed if I am trying to extract a datatype that is different from the internal datatype. But this is exactly what I want to stay away from, unless, of course I am missing something, which I would very like understand. > b) Breaking encapsulation includes referencing internal .h files in your > own code. You should be using sqlite3.h *only* > I am not referencing ANY internal.h file in my own code. I am just using the amalgamation distribution, and I am writing code in sqlite.c, not in my own source files, so nobody outside of sqlite.c calls any function or uses any datatype that is not declared in sqlite.h. > 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. > True, agreed. This is the reason why the types of each value being inserted into, updated and read from the database is strictly enforced outside of sqlite. To state in a cear way: SQLite might not enforce declared types, by the application around sqlite has been specifically designed to enforce different types. > > c) There is no guarantee that the internal fields referring to a previous > state of a Mem structure are preserved across conversions. > why do you refer to a "previous state of a mem structure"? the code is being executed inside a custom sqlite_exec function, which mirrors the behaviour of the provided sqlite_exec function, except for the conversions to/from text (which return the pointer to the internal data type, without any conversion in case of Integer and float value), WAY before calling the statement finalization. The callback itself that must be provided to sql3_exec, is called before finalizing and freeing the memory allocated by the statement execution. > 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. > Again good point, but we are 'lucky' here as well... sqlite amalgamation is compiled into the application and not dinamically linked. I know that what I am doing is hazardous, rings alarm bells, 'dirty' (if you want to call it dirty), I know that it could be done in several different ways, it's just that sqlite3_exec does already an excellent job in wrapping prapared statemets, stepping and finalizing the statement itself; it does return an array of stringified column values, and that's what I would like to avoid (in the case of integers and floats). Looking forward to reading more insights, hints, tips, suggestions, arguments, advice, whatever. Thanks _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
