I believe that's the entire point of this blog post. I'm rather puzzled to see the negative attention it has received.
Is this a huge pain point? No, but it is a constant niggling annoyance when using SQLite to power things like desktop apps.
If not built in to the core, I believe that SQLite supports compile-time extensions, would someone more knowledgeable comment?
I wonder if the OP would be satisfied with one of those? I personally would be fine building my own SQLite to get the functionality and it looks like the author would as well.
In short, I'm kind of confused as to why everybody seems so down on this idea. If an extension could be developed to do this, and if this extension would meet the OP's needs, I'm not sure why we're all going on about how it would ruin the sanctity and tininess of core SQLite. I'll put my $200 pledge here.
Yeah, I'm also surprised to see people so upset about the idea of the feature mostly for the argument that it doesn't presently exist. As for the compile-time-extension, my main concern with that as a free software project is that we try to play nice with distro packaging and requiring users to compile their own sqlite would be setting them up for a bit of pain. But I suspect it doesn't matter: if the feature was coded with the aim of pushing it upstream, I'm suspecting there's a good chance upstream would accept it if of good quality.
Code is unlikely to be accepted upstream because it very rarely is (assuming you mean by the SQLite team). They are very picky about code contributions and almost always implement themselves. One part is legal - there has to be very clear lineage/authoring to the code, patent clearances etc.
The second part is that the actual code to implement any particular functionality or even a bug fix is relatively trivial. There is far more effort and far more lines of code for testing: http://www.sqlite.org/testing.html - and implementing code to enable the rigourous testing usually results in a different structure.
