On Fri, Apr 10, 2015 at 2:42 AM, Richard Hipp <drh at sqlite.org> wrote:
> On 4/9/15, Roger Binns <rogerb at rogerbinns.com> wrote: > > For each function, its name... > > As it happens, the SQLite documentation build process already parses > out most of this and puts it into a database already. If you > check-out the documentation sources > (https://www.sqlite.org/docsrc/timeline) and successfully build the > documentation, it creates a > docinfo.db file that contains a lot of what you have requested above. > Probably it just needs to be enhanced a little. Most of the relevant > information is extracted from sqlite3.h using the > https://www.sqlite.org/docsrc/artifact/5c48dd261dbe5804 script. But that's build time. There is no way (i.e. pragma) to list registered SQL functions at runtime. This is something that I've asked for before, and I'm having trouble understanding why nobody cares. When you run an SQLite "shell", the host program can have enabled/disabled built-in functions at build-time, and/or added any number of custom SQL functions. But you have no way to know. Even in the sqlite3 shell, the .load of extensions often triggers registrations of new functions, and again you cannot know about this new function(s) (or vtable module(s)). You have to a-priori know all this, yet tools (the sqlite3 shell, the myriad GUI shells out there) can't allow you to introspect all that. That's a shame IMHO. The info exists inside the runtime, all that's missing are the pragmas to extract them. Can we please add these pragmas? The "truth" is in the "code", especially with SQLite where features (and thus functions) can be turned on/off at build-time. Neither the website or the doc are the "truth" of what you are running, which is why we need a "programmatic" way to get the info at runtime. My $0.02. --DD PS: Roger could then just *run* these pragmas and with some good naming convention fetch additional info from the website to embed the 1-liner doc he wants. (sqlite3 the shell tool should ideally provide built-in 1-liner doc for the functions as well, but I already hear all the "Lite-in-SQLite is not for nothing" if I even proposed to include that in the library itself, or allow custom function to provide such a doc snippet during registration...).
