On Wed, Jun 03, 2015 at 06:04:29PM -0700, Darko Volaric wrote: > Yep, references a another one. Just like the functions, you have to join on > the user type information, add it to constraints, etc.
Once you're extending SQLite3 proper the referential integrity problem goes away (being no different than the "problem" SQLite3 has of tracking value types internally). > In my case I'm already modifying and maintaining my own version of SQLite. > My project is basically a database with a lot of extensions. Submitting > patches is not an issue. 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. The > critical parts of SQLite (like the record read/write) are very stable and > updates hardly ever affect me. I'm not at all sure that UDTs are a bad idea. I do want JSON support, preferably using jq for expressing transformations (or merely addressing specific values in a JSON text) of JSON texts. And I'd like bigint (and bigfloat?) support. Those two types should be enough for easily dealing with a great many needs for UDTs without necessarily having support for arbitrary UDTs. A bitstring type would also be convenient for things like IP addresses and CIDR. Given that SQLite3 is in the public domain, you're not obliged to share your development. But who knows, in spite of all the reasons that using your "fork" would not be advisable, you might succeed in forming a community of users. So unless you have reasons not to share your work, I'd encourage you to share it. If you do share it, you'll want to give it a distinct name (it wouldn't be SQLite3, would it), and you'll want to very careful whose patches you accept: if you want to ever be able to contribute your changes back into the mainline, you'll need to be able to show that each contribution is permitted by the contributor's employer and so on. I have a long wishlist of features or changes that I don't think the SQLite3 developers are going to be very interested in at this time. You might not be either, but if there was a community of external developers that could pool its resources to make contributions that might be welcomed by the SQLite3 developers... Nico --
