| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Gregory Stark <stark(at)enterprisedb(dot)com> |
| Cc: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>, "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 16:04:45 |
| Message-ID: | 8535.1203523485@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs pgsql-docs |
Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> writes:
>> 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.
md5 is designed to be a signature, remember? If there weren't a very
high probability of its output being different for different inputs,
it wouldn't be good for anything.
The built-in hash functions definitely cannot be relied on to not have
collisions, though.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2008-02-20 16:15:19 | Re: GetNewOidWithIndex can cause infinite loop on user tables(not catalog). |
| Previous Message | Michael Fuhr | 2008-02-20 14:41:54 | Re: BUG #3965: UNIQUE constraint fails on long column values |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Gregory Stark | 2008-02-21 11:07:58 | Re: BUG #3965: UNIQUE constraint fails on long column values |
| Previous Message | Michael Fuhr | 2008-02-20 14:41:54 | Re: BUG #3965: UNIQUE constraint fails on long column values |