On 2 Mar 2013, at 3:19pm, kyan <alfasud...@gmail.com> wrote: > Thank you for your response Simon. > > On Sat, Mar 2, 2013 at 3:51 PM, Simon Slavin <slav...@bigfraud.org> wrote: >> SQLite isn't at its root a DDL. It's a C API, fully documented here: >> >> <http://www.sqlite.org/capi3ref.html> >> >> That's SQLite and that's its full documentation. As designed, to add SQLite >> facilities to your programming project you simply include the C source code >> (.c and .h files) that implements those commands into your project. That's >> the 'amalgamation source' you see us talking about on this list. > > I am familiar with the C API. I have successfully built the > amalgamation with Embarcadero CBuilder, translated the C API to Object > Pascal and linked the .obj file that CBuilder output to Delphi > programs with success, This way I don't need to distribute the SQLite > dll, the C source is directly linked in Delphi. And I have written a > thin Object Pascal object layer on top of the C API which allows me to > use SQLite in Delphi programs.
What you did there for Delphi is roughly the same thing people who make SQLite DLLs do. They make a thin shim that allows them to use SQLite calls from something other than C. So you already know what they're doing. >> Any DDL you see is someone trying to make some or all of those things >> accessible as a DDL. People who make DDLs for SQLite can put as many or as >> few of these things into their DDL as they like, along with as many things >> they made up themselves as they like. There is more than one DDL and for >> all we know they might all be different to one-another. If you want to know >> about a particular DDL, go find the documentation for that DDL. > > But... if I understand correctly adding some DDL extensions to SQLite > would mean modifying its SQL parser so that it can parse e.g. the > expression "ALTER TABLE tab DROP COLUMN col" and its engine in order > to be able to execute it. Wouldn't that mean modifying the source? That would be one way to do it, but there are others. One would be to insert a check in whatever they use for '_exec()' so before it passed the statement to SQLite it would check to see if it was one they wanted to implement themselves. Then instead of passing just one statement to _exec() they could pass more than one or even do something entirely different themselves. >> (There are complications which mean that you cannot do exactly the above and >> expect everything to work perfectly. I'm using it just as a demonstration.) > > I am already doing that but it is very difficult to do with FKs. Yes, foreign keys are one example of why I included the text I put in the brackets. Nevertheless, you do now understand that there are no magic undocumented calls in SQLite that people are using to do things like his. Which is what your question was. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
