On Mon, Sep 8, 2014 at 6:32 PM, Nico Williams <n...@cryptonector.com> wrote: > On Mon, Sep 8, 2014 at 6:16 PM, Simon Slavin <slav...@bigfraud.org> wrote: >> On 8 Sep 2014, at 11:45pm, Nico Williams <n...@cryptonector.com> wrote: >>> It'd also be good to have JSON and XML support, possibly as an >>> loadable extension. That way XPath and similar expressions matching >>> document snippets in SQL string values could be used in SQL queries. >> >> Not so sure about that. There are JSON and XML extensions available for >> pretty-much every language out there. Do you feel they need to be tightly >> integrated with SQLite somehow ? > > No, I don't. I rather dislike the way Postgres did the hstore and the > subsequent JSON support. > > I should clarify: what I don't like is ad-hoc syntax. I would like a > way to embed arbitrary external languages like jq or XPath in SQL > expressions. > >>> It'd be *very* convenient if SQLite3 had a value type that corresponds >>> to loadable extensions' private types, and a protocol for releasing >>> and serializing values of such types. >> >> Ah, but there you struck gold. If this is to be adopted, SQLite needs a >> DataType of FILE. Complete with functions to do things like get a file's >> name, path, length, contents, and probably half a dozen other things that >> don't come to mind right now. In fact this might be useful for SQLite even >> if it isn't going to be used as an OpenDoc file container. > > Yes. Pretty please, with sugar on top? > > Nico > --
Hum, why not a URI data type instead? ref: http://en.wikipedia.org/wiki/URI_scheme or http://www.ietf.org/rfc/rfc3986.txt .This is a "proper superset" of a URL. And it could encompass many other "access methods". Some that are implemented in browsers are things like http://some.webpage.html, file:///path/to/local/file, mailto:user.n...@organization.net, ftp://user:passw...@host.com/subdir/file and lots of other possibilities. The RFC does not attempt to detail all possible scheme (the first thing in the name, before the first :). SQLite could implement the fetching of contents by doing something like loading a dynamic library at run-time which might look like: lib<scheme>.so or .dll Where <scheme> is the URI scheme. E.g. libftp.so or libhttp.so . If just used in a SELECT, SQLite would just return a string value equal to the value such as you might see in a browser. And if the contents were needed, a function such as fetch() might be use. E.g. SELECT FETCH(urifield) FROM table; would get the URI for each non-NULL value of "urifield", inspect the first portion for the scheme, load the proper library and then pass the URI as a string value to that routine. Of course, this is getting fairly involved. And what is done if such a library does not exist? Error out the entire SELECT? Return a NULL? It gets very complicated. And I'm sure Dr. Hipp will see more problems and implications that I could ever imagine. -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan Maranatha! <>< John McKown _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
