Re: BUG #3965: UNIQUE constraint fails on long column values
От | Heikki Linnakangas |
---|---|
Тема | Re: BUG #3965: UNIQUE constraint fails on long column values |
Дата | |
Msg-id | 47BC0E41.3040704@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: BUG #3965: UNIQUE constraint fails on long column values (Gregory Stark <stark@enterprisedb.com>) |
Ответы |
Re: BUG #3965: UNIQUE constraint fails on long column values
|
Список | pgsql-bugs |
Gregory Stark wrote: > "Heikki Linnakangas" <heikki@enterprisedb.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. > > Postgres's internal hash method is exposed for most data types as hashtext() > hashfloat8(), hashint4(), etc. These functions were chosen for their > lightweight design. > > Cryptographic security is important only if you're concerned with people being > able to intentionally create collisions. In this scenario that's probably not > a top threat. Conceivably someone could create a denial-of-service attack > slowing down your server by causing your indexes to become unbalanced. But it > would be fairly challenging to engineer. 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... -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-bugs по дате отправления: