| From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
|---|---|
| To: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> |
| Cc: | "Juho Saarikko" <juhos(at)mbnet(dot)fi>, <pgsql-bugs(at)postgresql(dot)org> |
| Subject: | Re: BUG #3965: UNIQUE constraint fails on long column values |
| Date: | 2008-02-20 11:51:47 |
| Message-ID: | 87tzk3x2uk.fsf@oxford.xeocode.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs pgsql-docs |
"Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> writes:
"Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> writes:
> Gregory Stark wrote:
>> "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> writes:
>>
>>> As others have pointed out, CREATE UNIQUE INDEX i ON ((md5(column)) is a pretty
>>> good work-around.
>>
>> Unless you need cryptographic security I would not suggest using MD5. MD5 is
>> intentionally designed to take a substantial amount of CPU resources to
>> calculate.
>
> Return type of hash* functions is just 32 bits. I wonder if that's wide enough
> to avoid accidental collisions? Depends on the application of course...
Oh, I missed that you were suggesting a UNIQUE index. That seems unsafe to me
even for md5 or its ilk. But that would depend on the application too.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's RemoteDBA services!
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2008-02-20 12:19:38 | Re: BUG #3972: ERROR: function 59015 returned NULL |
| Previous Message | Heikki Linnakangas | 2008-02-20 11:25:53 | Re: BUG #3965: UNIQUE constraint fails on long column values |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Fuhr | 2008-02-20 14:41:54 | Re: BUG #3965: UNIQUE constraint fails on long column values |
| Previous Message | Heikki Linnakangas | 2008-02-20 11:25:53 | Re: BUG #3965: UNIQUE constraint fails on long column values |