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
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 t
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 t
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 any
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.
Alvaro Herrera <[EMAIL PROTECTED]> writes:
>> Marko Kreen 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 emp
On Sun, Jul 03, 2005 at 12:57:54PM -0400, Tom Lane wrote:
> Marko Kreen 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 handle
On Sun, Jul 03, 2005 at 12:57:54PM -0400, Tom Lane wrote:
> Marko Kreen 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 h
Marko Kreen 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 decrypt su
On Sun, Jul 03, 2005 at 12:02:38PM -0400, Tom Lane wrote:
> Marko Kreen 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 function
Marko Kreen 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 NULL argume
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_sal
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 ret
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 FUNC
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. Shoul
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 effec
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 fo
On Thu, Mar 17, 2005 at 17:40:52 +0200,
Marko Kreen wrote:
> On Wed, Mar 16, 2005 at 07:46:23AM -0800, Moran.Michael wrote:
> > How do you encrypt() & decrypt() data of types INT4 or DATE?
> >
> > The PGCrypto methods encrypt() and decrypt() each take BYTEA as input:
> >
> > i.e.,
> > encr
On Wed, Mar 16, 2005 at 07:46:23AM -0800, Moran.Michael wrote:
> How do you encrypt() & decrypt() data of types INT4 or DATE?
>
> The PGCrypto methods encrypt() and decrypt() each take BYTEA as input:
>
> i.e.,
> encrypt( data::bytea, key::bytea, type::text)
> decrypt( data::bytea, key::b
Hello,
How do you encrypt() & decrypt() data of types INT4 or DATE?
The PGCrypto methods encrypt() and decrypt() each take BYTEA as input:
i.e.,
encrypt( data::bytea, key::bytea, type::text)
decrypt( data::bytea, key::bytea, type::text)
So how do you convert INT4 and DATE data into BYTE
20 matches
Mail list logo
