On Tue, Feb 23, 2010 at 6:39 PM, Kevin Grittner
>> Or somebody who uses the tsearch functions because they're
>> planning to not change their dictionaries.
> I didn't realize tsearch functions were volatile. Should they
> really be so?
Uhm, my mistake. They're stable. Ok, for that one I'll substitute a
function which uses pg_read_file knowing that the file in question
won't be changed. Perhaps it's a per-machine key or something like
>> Or builds a hash function by calling random after setting the seed
>> to a specific value -- this is actually a fairly popular strategy
>> for building good hash functions.
> I'd never seen that. I'm not sure I understand where that comes in
> useful, but if you've seen it enough to call it "fairly popular" I
> guess I have to accept it.
They have the useful property that it's hard for an attacker to
contrive data which has poor collision behaviour.
> Thanks for the examples. They did make me consider a real-life type
> of process which isn't currently implemented as a PostgreSQL
> function, but conceivably could be -- randomizing a pool of jurors
> to facilitate jury selection. My eyes are opened. :-)
I'm not actually sure I follow what you're picturing.
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2010-02-23 18:51:22|
|Subject: Re: [PATCH] backend: compare word-at-a-time in bcTruelen |
|Previous:||From: Tom Lane||Date: 2010-02-23 18:47:57|
|Subject: Re: [PATCH] 8.5 TODO: Add comments to output indicating version of pg_dump and of the database server |