Magnus Hagander wrote:
Magnus Hagander wrote:
That won't help; that would introduce the "embarrassment" of
having a known default password.
No it wouldn't unless the packagers set it up to do that. My
point is that when a packager (or source) runs initdb, it would
prompt for the postgres user password.
Practically every existing packaging of PG tries to run initdb as a
hidden, behind-the-scenes, definitely not-interactive procedure.
afaik, practically every existing packaging of pg has *already*
solved the problem and does not set trust as default anyway. ident
sameuser I think is the most common.
One thing I've thought about doing is to remove the default in initdb
completely and *force* the user to choose auth type. Packagers can
then just use that to set ident or whatever. and interactive users
can pick trust if they really need it, but it will be a known choice.
Since nobody comemnted on this, let me turn it around and ask: Does
anybody have any reason *not* to do this?
If not, I'll just make it happen... (that should at least make people
speak up :P)
It will break the buildfarm. Of course I can unbreak it by adding
"--auth=trust" to the initdb args (and if we go this route we'll need to
do that for the regression temp installs too), but we'd need every
buildfarm member to have upgraded before we put it in. Is that really
the sort of disruption you want right now?
cheers
andrew
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
