Sorry if I came across impolite or destructive. The way you are attempting to
do what you feel you need to raises a whole bunch of red flags, which I have
been trying to explain, based on 40+ years of coding experience from assembler
upwards (including COBOL, FORTRAN, BASIC, FORTH, PASCAL, C, lex, yacc and Perl).
As others have pointed out, it is safe and reasonable to write your own
replacement for sqlite3_exec(), as long as you call it something else and stick
to the documented interface.
Your diagnosis ("lots of time is wasted converting numeric data to text and
back again") is correct, I only happen to think that your proposed therapy
might easily kill the patient (and maybe some bystanders too).
-----Ursprüngliche Nachricht-----
Von: sqlite-users [mailto:[email protected]] Im
Auftrag von Barone Ashura
Gesendet: Dienstag, 30. Juli 2019 16:40
An: SQLite mailing list <[email protected]>
Betreff: Re: [sqlite] [EXTERNAL] sqlite3_exec without ubiqitous text conversions
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 <[email protected]> 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
[email protected]
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
[email protected]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
