On Sat, 02 May 2009 11:26:28 +0200
"Daniel Verite" <daniel@xxxxxxxxxxxxxxxx> wrote:
> Note that it returns a bigint because we don't have unsigned
> integers in PG. If you're OK with getting negative values, the
> return type can be changed to int.
> Otherwise if you need a positive result that fits in 32 bits, it's
> possible to tweak the code to use 15 bits blocks instead of 16,
> but then the input will have to be less than 2^30.
I need shorter values (because they should be easier to type.
To be sure to modify the function in a sensible way I really would
appreciate some pointer.
Still if it return
To further shrink the length of the result I was planning to to_hex
(actually it would be nice to have a fast to_35base [0-9a-z])... but
I wasn't able to find a way to convert back an hex string to an int.
x'fff' seems to work just for literals.
CREATE OR REPLACE FUNCTION pseudo_encrypt(value int) returns
bigint AS $$
DECLARE
l1 int;
l2 int;
r1 int;
r2 int;
i int:=0;
BEGIN
l1:= (value >> 16) & 65535;
-- modifying here seems trivial
r1:= value&65535;
-- l1:= (value >> 15) & B'111111111111111'::int;
-- r1:= value & B'111111111111111'::int;
WHILE i<3 LOOP
l2:=r1;
r2:=l1 # ((((1366.0*r1+150889)%714025)/714025.0)*32767)::int;
-- but what about this? where does it come from?
/*
r2:=l1 #
((((1366.0*r1+150889)%714025)/714025.0)*B'11111111111111'::int)::int;
*/ -- ??
l1:=l2; r1:=r2; i:=i+1;
END LOOP;
return ((l1::bigint<<16) + r1);
-- modifying here seems trivial
END;
$$ LANGUAGE plpgsql strict immutable;
Anything else to suggest or copy from?
--
Ivan Sergio Borgonovo
http://www.webthatworks.it
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
