Re: contrib/pgcrypto functions not IMMUTABLE?

On Sun, Jul 03, 2005 at 12:43:32AM -0600, Michael Fuhr wrote:
> On Sun, Jul 03, 2005 at 04:24:31PM +1000, Russell Smith wrote:
> > On Sun, 3 Jul 2005 03:32 pm, Michael Fuhr wrote:
> > > I've noticed that contrib/pgcrypto/pgcrypto.sql.in doesn't include
> > > a volatility category in its CREATE FUNCTION statements, so the
> > > functions are all created VOLATILE.  Shouldn't most of them be
> > > IMMUTABLE?  Or do the algorithms have side effects?
> >
> > I know the salt functions MUST stay volatile, as they produce different output
> > every time you call them.  I've not looked at the pgcrypto code, so I can't
> > make further comment than that.
> 
> Yeah, I see that gen_salt() needs to be volatile, but I was thinking
> about functions like digest(), encrypt(), decrypt(), etc., that
> would be expected to return the same output given the same input.
> For example, the core md5() function is immutable, but pgcrypto's
> digest() is volatile.  I was wondering if that's intentional or
> just an oversight.

Just an oversight.

Could you send a patch to -patches that fixes it?  It would take
some time to do it myself, as I am coding an additional feature
to the PGP functions, and all my free time goes to that.

And if you decide to do it, please make them all STRICT too,
_except_ encrypt/decrypt functions.  Thats an additional change
I have in the air for pgcrypto.sql.in.

As for the encrypt/decrypt functions, I am increasingly
favouring throwing error in case of NULL arguments.  I'm fearing
a scenario, where somebody sets a encrypted data field to NULL,
and the change goes undetected.  This may not be that relevant
for encrypt/decrypt as their integrity protection is almost
non-existant, but is very relevant for PGP functions, as
they offer very strong guarantees.

Does anybody see a scenario, where this would be unreasonable?

-- 
marko