I was a bit/very dull, schoolboy error :( re 32-bit - long week and it's
only Tuesday :)
Re: storing the length in the blob itself this would affect parsing the
serial types where, as now, you can determine the record length by looking
at the serial types and 'skip' through them to load a
On Tue, Mar 28, 2017 at 12:52 PM, Paul Sanderson <
sandersonforens...@gmail.com> wrote:
> I am sure Richard will correct me if I am wrong. But...
>
> The format for a record is
>
> 1. payload length varint
> 2. rowid varint (optional)
> 3. serial type array varint
> 4. serial types
> followed by
I am sure Richard will correct me if I am wrong. But...
The format for a record is
1. payload length varint
2. rowid varint (optional)
3. serial type array varint
4. serial types
followed by the data for the serial types
The issue are as I see them:
The payload length varint above, this is the
On Tue, Mar 28, 2017 at 11:08 AM, Richard Hipp wrote:
> On 3/27/17, Andrew Cunningham wrote:
> > Is it likely the maximum BLOB size will be increased in a not too distant
> > future version of SQLite?
>
> The maximum blob size could, in theory, be
On 3/27/17, Andrew Cunningham wrote:
> HI,
> Is it likely the maximum BLOB size will be increased in a not too distant
> future version of SQLite?
>
The maximum blob size could, in theory, be increased to 4GiB. But the
current file format will not accommodate anything
HI,
Is it likely the maximum BLOB size will be increased in a not too distant
future version of SQLite?
In a world of machines where 1TB memory is not unusual the current upper
limit of ~2GB is proving to be restrictive for my use.
One might suggest that storing binary data of that size using
6 matches
Mail list logo