>>>>> "Tom" == Tom Lane <t...@sss.pgh.pa.us> writes:
>> I'm prepared to give slightly more consideration to option #3: >> make the new code read the old format as well as the new one. Tom> If you think you can make that work, it would solve the problem. I was hoping to do it without changing the new format, but that turns out not to be achievable, thanks to the fact (which I just discovered) that the old hstore can leave unlimited amounts of wasted space at the end of the object (does this count as a bug?). It's doable via a small change to the new format of course. This would require some care in handling the (few) users of pgfoundry hstore-new, but all that means is that users of the pre-release hstore-new would have to ensure at least one update of stored data before doing a binary migrate to 8.5, which I think isn't too much of a burden. The other option would be to fix the wasted-space bug in the existing hstore, and document that stored data must be updated at least once subsequent to that fix before doing a binary migrate to 8.5. (The pathological case is _very_ rare, requiring an 0-length key with exactly 32kb of data, followed by a specific series of key lengths with values of length 1, and with more than 28kbytes of wasted space at the end of the value, and only on little-endian machines. The only way to get that much wasted space is to do several thousand iterations of UPDATE ... SET hs = hs || ''; each of which adds 8 bytes of wasted space to the end of the value. But even so, somebody, somewhere, probably has a value that matches...) -- Andrew (irc:RhodiumToad) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers