> > Per the discussion yesterday, here's a patch. There are two versions of
> > essentially the same function. They both take an int as the number of
> > requested random bytes, and generate a random binary string of the
requested
> > length from /dev/urandom. The first one (randomstr_hex) converts the
binary
> > to hex and returns it as text, and the other (randomstr_bytea) does the
> > needed escaping of special characters and returns bytea.
>
> Perhaps one of these returning bytea would be enough and you can use
> the new encode functions to convert them to a format of choice. Also, why
> aren't you using /dev/random?
Very nice. I hadn't looked encode/decode yet. I'll rework the patch and just
leave the bytea as you suggested.
As far as /dev/random, the issue it that it blocks when it runs out of
entropy. As a small test, I recompiled with /dev/random and tried:
select randomstr_bytea(8), foo from bar;
where bar has about 120 rows. I was still waiting a minute later. When
requesting one at a time (but resubmitting relatively quickly), it works
fine until about the 35th request in a row, then it blocks briefly (~2
seconds). The same test with /dev/urandom returns instantly. Perhaps there
should be an option to use either. For instances where only a few truly
random bytes is needed (i.e. one session key), use /dev/random. When you
need many random bytes quickly, use /dev/urandom?
-- Joe
