Andrew Dunstan wrote:
>
>
> 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?
Ouch. No. Didn't think of that.
If we want to do that, we should probably do it right at the start of
the 8.4 cycle then?
//Magnus