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