From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Gregory Stark <stark(at)enterprisedb(dot)com> |
Cc: | PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Small Release Notes Comment |
Date: | 2007-11-01 22:38:11 |
Message-ID: | 200711012238.lA1McBx10993@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Gregory Stark wrote:
>
> I think the change to the hash functions needs to be called out in the release
> notes.
>
> If anyone stored any results of hashintN, hashfloat8, etc in their database or
> outside the database those results will have changed. It's fairly unlikely but
> there could be someone out there doing that.
>
> No intervention is required for normal expression indexes using those
> functions or hash indexes which will be rebuilt during a database upgrade
> anyways. I don't think hash_any itself changed so this wouldn't affect
> hashtext or any hash function which was already using hash_any.
Agreed. Added to the Migration section of the 8.3 release notes:
<listitem>
<para>
Internal hashing functions are now more uniformly-distributed (Tom)
</para>
<para>
If application code was calling and storing hash values using
internal <productname>PostgreSQL</> hashing functions, the hash
values must be regenerated.
</para>
</listitem>
I assume people will realize this does _not_ affect md5(), or should I
add a mention of that too.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2007-11-01 22:41:41 | Re: Re: [COMMITTERS] pgsql: Close previously open holes for invalidly encoded data to enter |
Previous Message | Pavel Stehule | 2007-11-01 20:57:27 | Re: beta2, I can't set UTF-8 for czech locales on win |