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
