From: | "Joe Conway" <joseph(dot)conway(at)home(dot)com> |
---|---|
To: | "Joe Conway" <joseph(dot)conway(at)home(dot)com>, "Peter Eisentraut" <peter_e(at)gmx(dot)net> |
Cc: | "Dr(dot) Evil" <drevil(at)sidereal(dot)kz>, <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: Random strings |
Date: | 2001-08-09 07:02:58 |
Message-ID: | 003701c120a1$5319fc80$0205a8c0@jecw2k1 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-patches |
> > 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?
>
Here's a revised patch. This one has only one user function, randomstr(int
binlen, text source). It allows any length request (well, limited by int)
against a source of 'urandom', or a maximum of 64 bytes against a source of
'random'. I also added a couple of examples to the readme to show how to use
randomstr() with encode() to get hex or base64 output.
On a side note, in the last version of this, I had a function which escaped
the binary C string so that I could feed it to byteain. In this version, I
decided to populate the varlena struct directly, because it seemed an awful
waste to escape the binary just so that byteain could unescape it. But I'm
not sure this is considered a "good thing", or a "bad thing". I'd appreciate
any guidance.
Thanks,
Joe
Attachment | Content-Type | Size |
---|---|---|
randomstr_r02.diff | application/octet-stream | 10.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Digital Wokan | 2001-08-09 07:48:15 | Re: Encrypting columns, security |
Previous Message | Allan Engelhardt | 2001-08-09 06:36:10 | Re: Re: First Saturday and Last Saturday of a month |
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Clift | 2001-08-09 10:07:08 | Re: [PATCHES] Re: can't make src/tutorial |
Previous Message | Bruce Momjian | 2001-08-09 03:13:45 | Re: [PATCHES] Re: can't make src/tutorial |