Robert Haas wrote:
On Sun, May 22, 2011 at 11:49 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I believe, however, that applying this will invalidate the contents of
any hash indexes on array types that anyone has built using 9.1beta1.
Do we need to do
On Sun, May 22, 2011 at 11:49 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I believe, however, that applying this will invalidate the contents of
any hash indexes on array types that anyone has built using 9.1beta1.
Do we need to do something about that?
On Fri, May 20, 2011 at 1:43 AM, Dean Rasheed dean.a.rash...@gmail.com wrote:
Doh! I forgot one important piece of this algorithm - it is necessary
to initialise the result to something non-zero at the start so that
adding leading nulls to an array changes the final result.
Looks reasonable.
Robert Haas robertmh...@gmail.com writes:
I believe, however, that applying this will invalidate the contents of
any hash indexes on array types that anyone has built using 9.1beta1.
Do we need to do something about that?
Like bumping catversion?
I would probably complain about that, except
On 19 May 2011 15:33, Robert Haas robertmh...@gmail.com wrote:
On Tue, May 17, 2011 at 2:44 PM, Dean Rasheed dean.a.rash...@gmail.com
wrote:
The algorithm for this was discussed in the original thread
(http://archives.postgresql.org/pgsql-hackers/2010-10/msg02050.php)
but I don't that think
The algorithm for this was discussed in the original thread
(http://archives.postgresql.org/pgsql-hackers/2010-10/msg02050.php)
but I don't that think a satisfactory conclusion was really reached.
In particular, it is way too easy to come up with pathological cases
that defeat the hashing