[SQL] md5 in pg_shadow?
Hi,
I was trying to write a function to validate the username and its password in
the pg_shadow table. The function should take in the username and password as
arguments and see if it matches with those in the pg_shadow table. But the md5
hashed password in pg_shadow doesnot match with what i get when i do
select 'md5' || md5('some_password');
Is there a function already present to do this or how can i get the same hashed
password that i get in pg_shadow so i can write my own function?
Please help me out on this.
Thanks,
Subhash.
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [SQL] md5 in pg_shadow?
On Thu, May 12, 2005 at 03:01:17PM -0600, [EMAIL PROTECTED] wrote:
>
> I was trying to write a function to validate the username and its password in
> the pg_shadow table. The function should take in the username and password as
> arguments and see if it matches with those in the pg_shadow table. But the md5
> hashed password in pg_shadow doesnot match with what i get when i do
> select 'md5' || md5('some_password');
Try this:
SELECT 'md5' || md5('some_password' || 'some_user');
--
Michael Fuhr
http://www.fuhr.org/~mfuhr/
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [SQL] interesting SQL puzzle - concatenating column with itself.
Nick Fankhauser <[EMAIL PROTECTED]> writes: > Alvaro Herrera wrote: > > > The order is not really guaranteed, though if this is a one-shot thing, > > you may get away with turning off hashed aggregates. > > > > When I read this, I assumed there was a runtime parameter I could set that was > similar to ENABLE_HASHJOIN. Are you referring to a different runtime parameter > or something else entirely? Similar but different. enable_hashagg. You can see all of these with "show all" in psql. However you do not have to worry. Even with (actually, *especially with*) hash aggregates the records will be processed in the order they're received. It's actually the normal aggregate method of sorting on the GROUP BY columns that risks damaging the order. However Postgres does a special check to see if the subquery is already sorted by the GROUP BY column and avoids the extra sort which could cause you problems. So this is not guaranteed by the SQL spec to work (but then the SQL spec doesn't have custom aggregates at all) but Postgres goes out of its way to make sure this doesn't break unnecessarily. [This is all for 8.0 and I think 7.4. Some versions before that might -- greg ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
