On 2 Jul 2012, at 6:27pm, Nico Williams <n...@cryptonector.com> wrote:
> A pair of built-in functions could take care of the user-friendliness > aspect to some degree, but built-in literals for bit string and IPv4/6 > CIDR notation would so much more user-friendly... IMO it's worth > doing. It's really quite common to store IP addresses in relational > databases... Your argument is for SQLite to allow users to implement their own affinities (datatypes ?) must like SQLite3 allows users to implement collation algorithms and functions. But I don't think you're going to get something as rarely used in SQLite4 when it's specially designed to be tiny and light. SQLite stays that way by refusing to add rarely-used facilities. But I still question whether you're engaged in premature optimization. Would things really be that much slower if you stored IPv4/6 as Higits ? IPv4 stored as hex is readable, sortable, can be transferred from place to place as an 8 character string and works perfectly with the standard distribution of SQLite3 with no changes. Implement conversion in- and out- functions either as SQLite functions or in your programming language, as suits you. You're concerned about the performance you lose by storing 10 octet strings instead of having a custom type ? Possibly if you're running a major ISP or doing packet analysis and logging for one. But you wouldn't be using SQLite to do that anyway, you'd be running something with built-in caching and redundancy. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
