Re: [sqlite] [EXTERNAL] sqlite3_exec without ubiqitous text conversions

2019-07-31 Thread James K. Lowden
On Wed, 31 Jul 2019 12:05:05 +0200 Olivier Mascia wrote: > Nothing stops any piece of your own programming or anyone using the > CLI to do: > > INSERT INTO "VALUES"(value_int) VALUES('something'); Not nothing, just nothing automatic. value_int INTEGER not NULL

Re: [sqlite] [EXTERNAL] sqlite3_exec without ubiqitous text conversions

2019-07-31 Thread Barone Ashura
Thanks! this helped me a lot in understanding the red flags. I think I have read the 'type affinity' documentation pages quite a few times (including this morning). Il giorno mer 31 lug 2019 alle ore 12:05 Olivier Mascia ha scritto: > > Le 31 juil. 2019 à 10:03, Barone Ashura a > écrit : > >

Re: [sqlite] [EXTERNAL] sqlite3_exec without ubiqitous text conversions

2019-07-31 Thread Olivier Mascia
> Le 31 juil. 2019 à 10:03, Barone Ashura a écrit : > > CREATE TABLE "VALUES" ( > id INTEGER PRIMARY KEY ASC, > value_int INTEGER, > value_double REAL, > value_text TEXT > ); > > and that I want to execute the following simple query: > > SELECT * FROM "VALUES"; > > For this very specific

Re: [sqlite] [EXTERNAL] sqlite3_exec without ubiqitous text conversions

2019-07-31 Thread Barone Ashura
> Why do it this way? Why not write your own custom_sqlite3_exec(...) that uses the standard, > stable, documented interfaces? Because sometimes I take wrong turns despite my best intentions :) But I usually smell it, when I am taking wrong turns, and that is why I can up here asking for

Re: [sqlite] [EXTERNAL] sqlite3_exec without ubiqitous text conversions

2019-07-31 Thread Hick Gunter
2019 16:40 An: SQLite mailing list 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 i

Re: [sqlite] [EXTERNAL] sqlite3_exec without ubiqitous text conversions

2019-07-30 Thread Barry
Why do it this way? Why not write your own custom_sqlite3_exec(...) that uses the standard, stable, documented interfaces? custom_sqlite3_exec(...) could call prepare / step / finalize, and use the standard sqlite3_column_* interfaces to fill a result array. This would be very little work and

Re: [sqlite] [EXTERNAL] sqlite3_exec without ubiqitous text conversions

2019-07-30 Thread Barone Ashura
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

Re: [sqlite] [EXTERNAL] sqlite3_exec without ubiqitous text conversions

2019-07-30 Thread Hick Gunter
users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] Im Auftrag von Barone Ashura Gesendet: Dienstag, 30. Juli 2019 14:51 An: SQLite mailing list Betreff: Re: [sqlite] [EXTERNAL] sqlite3_exec without ubiqitous text conversions Thanks for the response you gave me the kind of answer I was l

Re: [sqlite] [EXTERNAL] sqlite3_exec without ubiqitous text conversions

2019-07-30 Thread Barone Ashura
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,

Re: [sqlite] [EXTERNAL] sqlite3_exec without ubiqitous text conversions

2019-07-30 Thread Hick Gunter
What you are doing is a very bad idea indeed. a) you are circumventing the intended interface 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 c) you are assuming that type