"Michael Fuhr" <[EMAIL PROTECTED]> writes:
> On Wed, Feb 20, 2008 at 12:21:03PM +0100, Francisco Olarte Sanz wrote:
>> On Wednesday 20 February 2008, Gregory Stark wrote:
>>
>> > Unless you need cryptographic security I would not suggest using MD5. MD5
>> > is intentionally designed to take a sub
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Heikki Linnakangas" <[EMAIL PROTECTED]> 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 UN
On Wed, Feb 20, 2008 at 12:21:03PM +0100, Francisco Olarte Sanz wrote:
> On Wednesday 20 February 2008, Gregory Stark wrote:
>
> > 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.
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
>> "Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
>>
>>> As others have pointed out, CREATE UNIQUE INDEX i ON ((md5(column)) is a
>>> pretty
>>> good work-around.
>>
>> Unle
Gregory Stark wrote:
"Heikki Linnakangas" <[EMAIL PROTECTED]> 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 amo
On Wednesday 20 February 2008, Gregory Stark wrote:
> 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.
I thought it was the exact opposite, quoting from RFC1321:
The MD5 algorithm i
"Heikki Linnakangas" <[EMAIL PROTECTED]> 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 resourc
Juho Saarikko wrote:
I suggest implementing unique hash indexes and automatically creating one
(and turning the b-tree index into a non-unique one) when a large value is
inserted to fix this. Alternatively, fix b-trees so they can handle large
values; however, a hash index should be far more effi
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Juho Saarikko wrote:
While I didn't test, I'd imagine that this would also mean that any attempt
to insert such values to an already unique column would fail.
Works here in 8.3:
test=> crea
On Mon, 18 Feb 2008, Bruce Momjian wrote:
Juho Saarikko wrote:
While I didn't test, I'd imagine that this would also mean that any attempt
to insert such values to an already unique column would fail.
Works here in 8.3:
test=> insert into test values (repeat('a', 5) || 'b');
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Juho Saarikko wrote:
>> While I didn't test, I'd imagine that this would also mean that any attempt
>> to insert such values to an already unique column would fail.
> Works here in 8.3:
> test=> create table test (x text unique);
> N
Juho Saarikko wrote:
> While I didn't test, I'd imagine that this would also mean that any attempt
> to insert such values to an already unique column would fail.
Works here in 8.3:
test=> create table test (x text unique);
NOTICE: CREATE TABLE / UNIQUE will create implic
"Juho Saarikko" <[EMAIL PROTECTED]> writes:
> It is propably impossible to fix this in a simple way, since it is an
> inherent result of the underlying storage specification rather than a mere
> programming error, so the documentation needs to be updated to warn about
> this.
Point taken.
> I s
The following bug has been logged online:
Bug reference: 3965
Logged by: Juho Saarikko
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3RC2
Operating system: Linux
Description:UNIQUE constraint fails on long column values
Details:
It is impossible to add an U
14 matches
Mail list logo
