On Mon, Sep 8, 2014 at 8:05 PM, John McKown <john.archie.mck...@gmail.com> wrote: > Hum, why not a URI data type instead? ref:
Because we're talking about a purely internal type, with internal linkage. Externally it would appear as TEXT or BLOB. You'd use the TEXT type to store JSON, XML, ..., BLOB to store binary encodings. Internally you need to parse and serialize these things at the boundaries. If the boundaries are the existing ones then you end up parsing and serializing more than if the boundaries were just the file format. What I've got in mind is an extension to the loadable extension framework that allows each extension to add one (or more) pseudo-type(s) that have: a parser, a serializer, a copy/incref, and a release/decref operations, and probably nothing else. Those operations would be the internal linkage. API-wise there would be new statement parameter binding and cursor column accessors for using pseudo-types instead of TEXT/BLOB, but if these aren't used you'd get TEXT/BLOB. Language-wise there'd be not much special: virtual tables and user-defined functions are enough, really. If you ran a SELECT in the sqlite3 shell you'd get TEXT or BLOB results, but if you ran it using the C API you could access the internal extension type (e.g., the C 'jv' type provided by libjq). Nico -- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
