default postgres user and password

pg_roles is not the view that can tell whether a user has a password or not, because the password field is always set to ******** no matter what.

This comes from the definition of this view (taken from version 9.3):

select definition from pg_views  where viewname='pg_roles';

Result:

  SELECT pg_authid.rolname,
     pg_authid.rolsuper,
     pg_authid.rolinherit,
     pg_authid.rolcreaterole,
     pg_authid.rolcreatedb,
     pg_authid.rolcatupdate,
     pg_authid.rolcanlogin,
     pg_authid.rolreplication,
     pg_authid.rolconnlimit,
     '********'::text AS rolpassword
     pg_authid.rolvaliduntil,
     s.setconfig AS rolconfig,
     pg_authid.oid 
    FROM (pg_authid
    LEFT JOIN pg_db_role_setting s
      ON (((pg_authid.oid = s.setrole) AND (s.setdatabase = (0)::oid))));

Note how the rolpassword column is hardcoded to reveal nothing (We may wonder why it's there at all. Maybe for backward compatibility?)

On the other hand , there is a pg_shadow view that displays passwords as they're stored, in a column named passwd. This view is only readable by a superuser (typically: the postgres user).

Example:

create user foo unencrypted password 'foopassword';
create user bar encrypted password 'foopassword';
select usename,passwd from pg_shadow where usename in ('postgres','foo','bar');

Result on a vanilla Debian install:

 usename  |               passwd                
----------+-------------------------------------
 postgres | 
 foo      | foopassword
 bar      | md50390570d30cb9a2f9cb7476f0763cf51

Initially the postgres password is often empty, except on Windows for which the installer tends to ask for it. On Unix, pg_hba.conf is often set up such that only the OS user postgres may log in as the database user postgres through Unix socket domains without a password. This is reasonable as a default security policy. Windows doesn't have Unix domain sockets, and the most recent versions of the installer don't even use a postgres OS user, so it makes sense that it implements a different default security policy.

If a password is blank and the pg_hba.conf requires a password for the particular database/user/origin of an incoming connection, then the connection is rejected. There's no difference between a blank password and a lack of password.