On Tue, Feb 23, 2010 at 6:39 PM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
>> 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
that.
>> 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.
http://en.wikipedia.org/wiki/Universal_hashing
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.
--
greg
