Re: function side effects

On Tue, Feb 23, 2010 at 6:39 PM, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)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