Tom Lane wrote:
> I wrote:
>> If we wanted to keep the lengths in the same 32 bits they presumably
>> occupy now, what about splitting 8/24 (=> 255 bytes for key, 24MB for
>> value)?
>
> Sigh, fingers faster than brain today. A 24-bit length field could
> represent lengths up to 16MB, not 24MB. Still, it seems like a
> reasonable maximum.
>
> Or we could increase the size of hstore values so as to provide more
> than 32 bits total for this, but that would presumably be pessimal for
> all existing applications; there is evidently no one using more than
> 64K, or we'd have heard complaints before.
Yeah, I have to say that it would never have occurred to me to use
hstore for large values like that; 64K is pretty much a whole page of
text. If you need to store that much data, use a real table. Or maybe
CouchDB.
As an hstore user, I'd be fine with simply limiting it to 64K (or, heck,
8K) and throwing an error. I'd also be fine with limiting keys to 255
bytes, although we'd have to warn people.
--Josh