I committed a few changes to the user creation code which should, in
theory, make them more robust (doesn't use pg_exec_query_dest anymore).
Due to an inherent design conflict the update of the password file cannot
use the COPY logic anymore (the copy command wouldn't see the last changed
tuple), so it does it itself now, which looks better to me anyway. The
format of the file is still the same, I just filled up the unused spots
with x's and 0's. The remaining problem is initdb, which writes the
initial pg_pwd with COPY, so we can't go to a different, more compact
format yet. A solution for this would be to scrap this call and instead
call
echo "ALTER USER $POSTGRES WITH PASSWORD '$WHATEVER'" | postgres ...
in initdb and forget about all the scary sed -f or similar things that
have been proposed recently to get the password in there securely. That
way we can be assured to have the password file always in the format it
will be later on.
Bruce, are you still working on that part?
A few other side effects of the changes were:
* Even unprivileged users can change their own password (but nothing else)
* The password is now an Sconst in the parser, which better reflects its
text datatype and also forces users to quote them.
* If your password is NULL you won't be written to the password file,
meaning you can't connect until you have a password set up (if you use
password authentication).
* When you drop a user that owns a database you get an error. The database
is not gone.
These are minor "wholesale" changes, but I thought they would be in the
public's interest.
--
Peter Eisentraut Sernanders väg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden