That's an entirely valid point, but didn't come up in the discussions if memory serves. It was the "you don't know what you're doing and don't understand databases" which I thought was an odd response, but that's all irrelevant.
I agree that feature bloat is not a good idea (hello, PgSQL!) and I don't want to add features but rather programming interfaces. I don't make extensive changes to the code at all. I basically try to provide hooks in the code that don't actually change any functionality. For instance my UDTs design just adds a few bits to the record header that associates a small, unsigned integer with a stored field, nothing more. These bits have no impact on any code that is not aware of them. It was the most minimal design I could think of. Similarly with the VM. I don't add opcodes nor do I change the form or semantics of the existing codes, but I do sneak "links" into unused opcode parameters which are interpreted by my own code, kind of like running a VM of my own alongside. In other places I just use private functions as if they were public APIs. I think this is the sort of approach is beneficial to SQLite, especially since it's an embedded database and it's very natural to want to extend it and intertwine it with your own code, if you need more than the stock functionality. I also understand that it makes the job of the developers harder and that they have no reason to put time into hooks or APIs used by a relative minority. I suspect most people who need extensions are like me and want something very particular and mix in their own proprietary code. For instance, I think programming in C is like a visiting a dentist who doesn't use lidocaine, so my actual functionality is in a completely different language. On Wed, Jun 3, 2015 at 11:52 PM, Dominique Devienne <ddevienne at gmail.com> wrote: > On Thu, Jun 4, 2015 at 3:04 AM, Darko Volaric <lists at darko.org> wrote: > > > In my case I'm already modifying and maintaining my own version of > SQLite. > > [...]. The last time I brought these ideas up I was > > practically chased off by a mob waving pitchforks and torches. Apparently > > almost no-one thinks user defined types is a good idea so there is no > point > > sharing it. I don't expect anyone to help me maintain the code. > > > FWIW, I think UDTs are a great idea. But also > - optional static typing of columns; > - checksums of blocks;- > - blob two-tier storage (a la Oracle); > - native indexing of virtual table; > - native JSON support; > - etc... > > Yes, the community, just like the authors, of SQLite have a strong bias > against changes and to keep SQLite "lite". > > And can be brutal in how they say it (or ignore it) when someone rants > about his pet-peeves, or try to push forward his wish list (including me > above). > > But remember that SQLite didn't have FKs for a long time. Didn't have CTE. > Both of which are major enhancements. So there's hope long term IMHO :). > > Now unlike most (including me again), you go further and actually code it > up apparently. That's great. But it's hard to fork SQLite and get any > traction given the fast-paced refactoring/optimization the main code goes > through. And also UDTs can have widespread side effects within SQLite, hard > to gauge w/o having the whole code-base and design in ones head like DRH. > Might be good enough for you, but not for the high quality standards which > is a hallmark of SQLite IMHO. All I can suggest is continue communicating > and perhaps also OSS your changes on GitHub or similar, and you may get > help somehow. > > I suspect (hope really) first-class UDTs in SQLite (as Nico calls them) > haven't been dismissed, and it's more a question of finding the time and > funding to do them right, i.e. in a "lite" way that doesn't adversely > affect SQLite if you don't use them, and thoroughly tested as usual. My > $0.02. --DD > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >
