Re: [sqlite] sqlite4: type decl/def discrepancy (w/ fix)

On 29 Jun 2012, at 17:17, Stephan Beal wrote: > If i can be of any assistance, i'm free to help this weekend. i feel kinda > bad about spamming the user list so much, though :/. No need to feel bad. It helps us to see "over the horizon". > Should we try to > convince the admin

Re: [sqlite] Consequences of lexicographic sorting of keys in SQLite4?

On 29 Jun 2012, at 23:58, Richard Hipp wrote: > But you know: How often do people use BLOBs as keys? What other SQL > engines other than SQLite even allow BLOBs as keys? Are we trying to > optimize something that is never actually used? For an IPAM application I have on my back

Re: [sqlite] Consequences of lexicographic sorting of keys in SQLite4?

On 07/02/2012 04:29 PM, Niall O'Reilly wrote: On 29 Jun 2012, at 23:58, Richard Hipp wrote: But you know: How often do people use BLOBs as keys? What other SQL engines other than SQLite even allow BLOBs as keys? Are we trying to optimize something that is never actually used? For

Re: [sqlite] Consequences of lexicographic sorting of keys in SQLite4?

On 2 Jul 2012, at 10:51, Dan Kennedy wrote: > That would be a reasonable use. But the blob in this case will be what, > eight bytes (or 10 in its encoded form)? 10, 18, 34, or 66, depending on which of six classes [*] of object is involved, using the encoding I have in mind at

Re: [sqlite] Consequences of lexicographic sorting of keys in SQLite4?

On 2 Jul 2012, at 10:29am, Niall O'Reilly wrote: > On 29 Jun 2012, at 23:58, Richard Hipp wrote: > >> But you know: How often do people use BLOBs as keys? What other SQL >> engines other than SQLite even allow BLOBs as keys? Are we trying to >> optimize something that

[sqlite] Blobs and ordering [was: Consequences of lexicographic sorting of keys in SQLite4?]

Simon, Thanks for your considered comments. On 2 Jul 2012, at 12:20, Simon Slavin wrote: > Worth remembering that BLOBs don't have a well-ordering function. You can > compare two BLOBs and tell whether they're the same (usually, but lossless > encoding defeats this), but if

[sqlite] database busy error

If I have a pool of external (c++) progs, all writing into the same sqlit3 db, how do i handle this correctly ? Now, sometimes I get db busy error (5) ___ sqlite-users mailing list sqlite-users@sqlite.org

Re: [sqlite] database busy error

On Mon, Jul 2, 2012 at 3:13 PM, deltagam...@gmx.net wrote: > If I have a pool of external (c++) progs, all writing into the same sqlit3 > db, > how do i handle this correctly ? > Now, sometimes I get db busy error (5) > See: http://sqlite.org/lockingv3.html Search for

Re: [sqlite] database busy error

> If I have a pool of external (c++) progs, all writing into the same sqlit3 db, > how do i handle this correctly ? I think it depends on your applications. We use sqlite for IPC and data sharing within processes on the same machine. I'm not suggesting it for you, but the following works for

Re: [sqlite] Consequences of lexicographic sorting of keys in SQLite4?

On Mon, Jul 2, 2012 at 4:29 AM, Niall O'Reilly wrote: > > On 29 Jun 2012, at 23:58, Richard Hipp wrote: > >> But you know: How often do people use BLOBs as keys? What other SQL >> engines other than SQLite even allow BLOBs as keys? Are we trying to >> optimize something

[sqlite] IP address support (was: Consequences of lexicographic sorting of keys in SQLite4?)

On 2 Jul 2012, at 16:13, Nico Williams wrote: > That reminds me: it'd be nice to have a bit string type, since the > correct way to sort IPv4 CIDR blocks is as bit strings. Nice, definitely! > This is also > a proper way to sort IPv6 blocks. Alternatively, it'd be nice to have >

Re: [sqlite] IP address support (was: Consequences of lexicographic sorting of keys in SQLite4?)

The key is to come up with a bit string encoding in bytes that is suitable for use in table keys -- they have to sort correctly when sorted lexicographically. The encoding should be reasonably efficient; one byte per-bit, for example, would be too inefficient (though in a pinch much better than

Re: [sqlite] IP address support (was: Consequences of lexicographic sorting of keys in SQLite4?)

Ah, if you encode any bit string as a BLOB such that it ends in 3 bits that encode the length of the string mod 8, and with 7 - length of string mod 8 preceding zero-valued bits then you get a result that should sort [lexicographically] correctly, no? So bit string would be a trivial extension of

Re: [sqlite] IP address support (was: Consequences of lexicographic sorting of keys in SQLite4?)

So an IPv4 CIDR block like 10.2.93.128/25 would encode as x'0A025D81' and 10.2.93.128/26 as x'0A025D82', and so on, with 10.2.93.128/32 encoded as x'0A025D8000' (that's 5 bytes). That is, IPv4 addresses would require one more byte than usual. I'm not sure that we can justify the extra complexity

Re: [sqlite] IP address support (was: Consequences of lexicographic sorting of keys in SQLite4?)

On 2 Jul 2012, at 17:52, Nico Williams wrote: > So an IPv4 CIDR block like 10.2.93.128/25 would encode as x'0A025D81' > and 10.2.93.128/26 as x'0A025D82', and so on, with 10.2.93.128/32 > encoded as x'0A025D8000' (that's 5 bytes). That is, IPv4 addresses > would require one more byte than

Re: [sqlite] Consequences of lexicographic sorting of keys in SQLite4?

On Mon, Jul 02, 2012 at 10:13:13AM -0500, Nico Williams scratched on the wall: > That reminds me: it'd be nice to have a bit string type, since the > correct way to sort IPv4 CIDR blocks is as bit strings. This is also > a proper way to sort IPv6 blocks. Alternatively, it'd be nice to have >

Re: [sqlite] IP address support (was: Consequences of lexicographic sorting of keys in SQLite4?)

On Mon, Jul 2, 2012 at 12:11 PM, Niall O'Reilly wrote: > On 2 Jul 2012, at 17:52, Nico Williams wrote: >> So an IPv4 CIDR block like 10.2.93.128/25 would encode as x'0A025D81' >> and 10.2.93.128/26 as x'0A025D82', and so on, with 10.2.93.128/32 >> encoded as x'0A025D8000'

Re: [sqlite] Consequences of lexicographic sorting of keys in SQLite4?

On 2 Jul 2012, at 18:20, Jay A. Kreibich wrote: > The idea of using a plugin system to expand database functionality > seems to fit well with the SQLite way of getting things done. > Functions, collations, and virtual tables are already done in a > similar way. Extending that to types seems

Re: [sqlite] Consequences of lexicographic sorting of keys in SQLite4?

On Fri, Jun 29, 2012 at 5:58 PM, Richard Hipp wrote: > > On Fri, Jun 29, 2012 at 6:40 PM, Nico Williams wrote: > > > On Fri, Jun 29, 2012 at 5:24 PM, Richard Hipp wrote: > > > varint+value does not sort BLOBs in lexicographical order. > >

Re: [sqlite] IP address support (was: Consequences of lexicographic sorting of keys in SQLite4?)

On 2 Jul 2012, at 6:27pm, Nico Williams 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.

Re: [sqlite] IP address support (was: Consequences of lexicographic sorting of keys in SQLite4?)

On Mon, Jul 2, 2012 at 1:14 PM, Simon Slavin wrote: > 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

[sqlite] max size of a TEXT field

Hello, I couldnt find in the documentation what the max size of TEXT field/column is. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] max size of a TEXT field

On 7/2/2012 4:02 PM, deltagam...@gmx.net wrote: I couldnt find in the documentation what the max size of TEXT field/column is. There's no set limit. As much as can fit into memory, basically. -- Igor Tandetnik ___ sqlite-users mailing list

Re: [sqlite] max size of a TEXT field

On Mon, Jul 2, 2012 at 4:02 PM, deltagam...@gmx.net wrote: > Hello, > > I couldnt find in the documentation what the max size of TEXT field/column > is. http://www.sqlite.org/limits.html#max_length By default it's 10^9 bytes and cannot be more than 2^31 - 1. Pavel

Re: [sqlite] max size of a TEXT field

On Mon, Jul 02, 2012 at 10:02:29PM +0200, deltagam...@gmx.net scratched on the wall: > Hello, > > I couldnt find in the documentation what the max size of TEXT > field/column is. First item: http://sqlite.org/limits.html#max_length By default, 10^9 bytes (~1GB). Can be altered, but there

Re: [sqlite] Consequences of lexicographic sorting of keys in SQLite4?

Richard Hipp writes: > The keys are encoded (see > http://www.sqlite.org/src4/doc/trunk/www/key_encoding.wiki) in a way > that causes a lexicographical ordering of the keys to correspond to > what the user wants out of ORDER BY. I don't understand

Re: [sqlite] max size of a TEXT field

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/07/12 13:20, Jay A. Kreibich wrote: > By default, 10^9 bytes (~1GB). Can be altered, but there is a hard > limit of (2^31 - 1), or 2GB. Even more subtleties than that. SQLite's internals are fundamentally 32 bits even on 64 bit platforms.

Re: [sqlite] sqlite3_bind_int64() on Solaris 10?

Our debug build works with CC compiler, while release build does not. Eventually we found out that it was "-fast" (specifically, "-xalias_level=basic" in "-fast") CC compiler option, that causes problems. We are wondering what GCC 4.3.3 compiler options were used for testing on Solaris