Nobody is storing pointers. Where do you get that idea? If struct pointer is passed through sqlite3_result_blob() with destructor callback disposition instead of SQLITE_TRANSIENT, the value received is a BLOB result pointed to the (void*) memory location of that exact supplied struct's memory. That's how it works now and independently of the 3.20.00 proposal.
Now, if that BLOB is persisted you get a copy of those bits onto the disk. So what? Maybe that makes sense or maybe not, but the pointer isn't stored. The pointer is only available at runtime which is what we're talking about here. The question is not about storage. The question is how to make the API useful for embedded applications with awareness of the host's transient objects. We also learned just now by forum email from Richard that adding and carrying a native INT type field throughout the chain of the existing BLOB API is too expensive. So he went with the lightweight pseudo-nulls idea. Take a look at my sample SQL a few emails back if you want to see an application. Most of the time the operational result of passing pointers to native objects through the DB API with respect to storage is null. The desired operation is often a side effect like sending something over the network or efficiently keeping track of whatever summarized results in a memory vtable. The important part from my perspective is that the DB can store precise details about embedded object initializations and interactions without having to invent a storage format for every little setting or add serialization methods to third party library objects lacking serialization operations. On Fri, Jul 21, 2017 at 3:14 PM, Keith Medcalf <kmedc...@dessus.com> wrote: > > Pointers cannot be stored in the database. They are simply value objects > that get passed around between bits and pieces -- such as passing a pointer > from an SQL statement into an extension function or virtual table all > within the same linkage unit (that is locally within a single process). > The whole point, I believe, was to prevent pointers from being persisted to > the database. And if you foolishly try to store them in the database, then > the value stored is NULL. Storing pointers in BLOBs would defeat this > purpose since you would not be preventing natural selection. > > And if I have the purpose wrong, then I really don't understand why there > needs to be a separate value type for pointers at all ... > > > >-----Original Message----- > >From: sqlite-users [mailto:sqlite-users- > >boun...@mailinglists.sqlite.org] On Behalf Of petern > >Sent: Friday, 21 July, 2017 14:49 > >To: SQLite mailing list > >Subject: Re: [sqlite] SQLite 3.20.0 postponed > > > >Indeed. Or Type(T) of long, or sqlite_int64, or whatever is most > >universal > >where porting other architectures is concerned. It would be a shame > >if the > >API had to be changed later because the integer type chosen couldn't > >hold a > >pointer. > > > >From there, in a closed compiled host C/C++ setting with the > >discipline of > >header files, one may simply perform the stricmp("CARRAY",(const > >char*) T) > >cast to T string pointer comparison as desired and leave the API out > >of > >that part. This leaves open the more conventional test of T with > >enum or > >#define compile time constant. > > > >Now it remains, on the surface, that this new pseudo null pointer API > >appears redundant in light of the existing BLOB interface and the > >possibility of simply adding Type(T) versions of those BLOB function > >signatures to the API. > > > >How was adding to the BLOB API ruled out? Is there a fundamental > >problem > >with slightly broadening the BLOB API to deal with typed host > >objects? > >Surely returning zero for the Type(T) would be backward compatible, > >would > >it not? Just asking. > > > > > > > > > > > > > > > > > > > >On Fri, Jul 21, 2017 at 12:48 PM, Keith Medcalf <kmedc...@dessus.com> > >wrote: > > > >> On Friday, 21 July, 2017 10:51, Richard Hipp <d...@sqlite.org> > >wrote: > >> > >> > But sqlite3_result_pointer() and sqlite3_bind_pointer() are not > >> > invoked from those languages. The _pointer() routines are > >invoked > >> > from C, and C does easily support string literals that are static > >> > strings. > >> > >> > A C-language wrapper around sqlite3_result_pointer() and > >> > sqlite3_bind_pointer() that interfaces to the non-static-string > >> > language can simply insert the required static string. > >> > >> Well, yes. Technically. Almost everything everywhere is called > >from code > >> written in C. Very little meaningful anything is written in any > >other > >> language. So although you may be writing something in Java > >(heavens > >> forbid), Java was written in C. So in the end, all calls are made > >from > >> software written in C. This is the way of the world. Some people > >just > >> like to add lots of syntactical sugar and overhead which eventually > >ends up > >> being C code -- either translated by a preprocessor (as in the case > >of > >> C++), or by a compiler written in C (or written in some other > >language that > >> was written in C ... repeat for as deep down the rabbit hole as you > >need to > >> go). There are a few self-hosted language compilers that are > >exceptions, > >> but not very many. And they all started as C before they were re- > >written > >> in themself so they could become self-hosted. > >> > >> However, the change does create a problem when one is using a > >sugary > >> language (for example Python). It does not know how to bind > >pointers, nor > >> is there any way to pass in a variable static "string" as an extra > >> parameter. So for example, the carray extension *used* to be able > >to be > >> passed a pointer which was bound as an int (you obtain the pointer > >by > >> allocating a ctypes array and asking for the pointer) -- of course > >this is > >> unsafe if you do something stupid -- but then almost everything > >including > >> making a nice cuppa tea is unsafe if you do something stupid. > >> > >> I have fiddled with defining a new type for the python interface > >that can > >> contain a string and a reference to a ctypes object (so that the > >string > >> stays in scope and the ctypes array stays in scope as long as the > >outer > >> object stays in scope), and then adding an addition bind detection > >for this > >> type of object. It works but it is far more complicated than just > >> modifying the carray extension so that it will accept integers for > >the > >> pointer (as well as pointer types). Plus of course (sending an > >integer) > >> works with all interfaces that can get a pointer rather than having > >to > >> update every single possible sugary extension. > >> > >> > >> > >> > >> > >> > >> _______________________________________________ > >> sqlite-users mailing list > >> sqlite-users@mailinglists.sqlite.org > >> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite- > >users > >> > >_______________________________________________ > >sqlite-users mailing list > >sqlite-users@mailinglists.sqlite.org > >http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > > > > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
