Skip site navigation (1) Skip section navigation (2)

Re: Random strings

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 (view raw, whole thread or download thread mbox)
Lists: pgsql-generalpgsql-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,
> > 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.



Attachment: randomstr_r02.diff
Description: application/octet-stream (10.3 KB)

In response to

pgsql-patches by date

Next:From: Justin CliftDate: 2001-08-09 10:07:08
Subject: Re: [PATCHES] Re: can't make src/tutorial
Previous:From: Bruce MomjianDate: 2001-08-09 03:13:45
Subject: Re: [PATCHES] Re: can't make src/tutorial

pgsql-general by date

Next:From: Digital WokanDate: 2001-08-09 07:48:15
Subject: Re: Encrypting columns, security
Previous:From: Allan EngelhardtDate: 2001-08-09 06:36:10
Subject: Re: Re: First Saturday and Last Saturday of a month

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group