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?
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
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
On Sun, Jul 03, 2005 at 03:59:51PM +0300, Marko Kreen wrote:
On Sun, Jul 03, 2005 at 12:43:32AM -0600, Michael Fuhr wrote:
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
On Sun, Jul 03, 2005 at 07:54:47AM -0600, Michael Fuhr wrote:
I'll submit a patch. Does the following look right?
digest IMMUTABLE STRICT
digest_exists IMMUTABLE STRICT
hmac IMMUTABLE STRICT
hmac_existsIMMUTABLE STRICT
crypt IMMUTABLE STRICT
gen_salt
Marko Kreen marko@l-t.ee writes:
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
On Sun, Jul 03, 2005 at 12:02:38PM -0400, Tom Lane wrote:
Marko Kreen marko@l-t.ee writes:
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
Marko Kreen marko@l-t.ee writes:
On Sun, Jul 03, 2005 at 12:02:38PM -0400, Tom Lane wrote:
That doesn't seem like a good idea at all. Why shouldn't an encryptable
value be NULL? I think you should just make 'em strict.
Well, I have mainly issues with decrypt part. I'd like
to say, if
On Sun, Jul 03, 2005 at 12:57:54PM -0400, Tom Lane wrote:
Marko Kreen marko@l-t.ee writes:
On Sun, Jul 03, 2005 at 12:02:38PM -0400, Tom Lane wrote:
That doesn't seem like a good idea at all. Why shouldn't an encryptable
value be NULL? I think you should just make 'em strict.
Well, I
On Sun, Jul 03, 2005 at 12:57:54PM -0400, Tom Lane wrote:
Marko Kreen marko@l-t.ee writes:
As for the crypt() case, lets say you have a new user with
hashed password field NULL. In addition, you have client
program that compares crypt() result with hashed field
itself, in addition it
Alvaro Herrera [EMAIL PROTECTED] writes:
Marko Kreen marko@l-t.ee writes:
As for the crypt() case, lets say you have a new user with
hashed password field NULL. In addition, you have client
program that compares crypt() result with hashed field
itself, in addition it handles NULL's as empty
Marko Kreen wrote:
On Sun, Jul 03, 2005 at 07:54:47AM -0600, Michael Fuhr wrote:
In the functions marked STRICT, should I leave the PG_ARGISNULL()
checks in place as a precaution? Removing those checks could cause
problems if people use the new code but have old (non-STRICT) catalog
entries.
On Mon, Jul 04, 2005 at 11:42:14AM +1000, Neil Conway wrote:
Assuming the STRICT / IMMUTABLE changes are only going into HEAD, you
can safely remove the PG_ARGISNULL() checks -- people upgrading from a
prior version of Postgres (and therefore pgcrypto) will need to dump and
reload anyway.
Michael Fuhr wrote:
But if they restore a dump made with pg_dump or pg_dumpall, they'll
get the old catalog entries sans STRICT, no? People might rebuild
the module when they upgrade, but they might not think to drop and
recreate the functions since the definitions are already in the
dump.
I
On Sun, Jul 03, 2005 at 08:15:07PM +0300, Marko Kreen wrote:
Michael, the result is, you can make them all STRICT.
OK. Does anybody else have thoughts on removing the PG_ARGISNULL()
checks? Neil suggests removing them because they'd be unnecessary,
but I'm concerned about people who'd use
Michael Fuhr [EMAIL PROTECTED] writes:
OK. Does anybody else have thoughts on removing the PG_ARGISNULL()
checks? Neil suggests removing them because they'd be unnecessary,
but I'm concerned about people who'd use the new code with old
catalog entries that aren't STRICT (e.g., restored from
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? So far I've
found no discussion about this except
17 matches
Mail list logo
