Re: disable prompting by default in createuser

I propose that we change createuser so that it does not prompt for
anything by default. We can arrange options so that you can get prompts
for whatever is missing, but by default, a call to createuser should
just run CREATE USER with default options. The fact that createuser
issues prompts is always annoying when you create setup scripts, because
you have to be careful to specify all the necessary options, and they
are inconsistent and different between versions (although the last
change about that was a long time ago), and the whole behavior seems
contrary to the behavior of all other utilities. I don't think there'd
be a real loss by not prompting by default; after all, we don't really
want to encourage users to create more superusers, do we? Comments?

On Fri, Nov 25, 2011 at 6:28 PM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> I propose that we change createuser so that it does not prompt for
> anything by default.  We can arrange options so that you can get prompts
> for whatever is missing, but by default, a call to createuser should
> just run CREATE USER with default options.  The fact that createuser
> issues prompts is always annoying when you create setup scripts, because
> you have to be careful to specify all the necessary options, and they
> are inconsistent and different between versions (although the last
> change about that was a long time ago), and the whole behavior seems
> contrary to the behavior of all other utilities.  I don't think there'd
> be a real loss by not prompting by default; after all, we don't really
> want to encourage users to create more superusers, do we?  Comments?

+1. I've never found the current behavior to be other than an
annoyance. I suggest --interactive or something like that to enable
prompting.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On lör, 2011-11-26 at 01:28 +0200, Peter Eisentraut wrote:
> I propose that we change createuser so that it does not prompt for
> anything by default. We can arrange options so that you can get prompts
> for whatever is missing, but by default, a call to createuser should
> just run CREATE USER with default options. The fact that createuser
> issues prompts is always annoying when you create setup scripts, because
> you have to be careful to specify all the necessary options, and they
> are inconsistent and different between versions (although the last
> change about that was a long time ago), and the whole behavior seems
> contrary to the behavior of all other utilities. I don't think there'd
> be a real loss by not prompting by default; after all, we don't really
> want to encourage users to create more superusers, do we? Comments?

Patch attached. I'll add it to the next commitfest.

On Thu, Dec 22, 2011 at 2:26 PM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> On lör, 2011-11-26 at 01:28 +0200, Peter Eisentraut wrote:
>> I propose that we change createuser so that it does not prompt for
>> anything by default.  We can arrange options so that you can get prompts
>> for whatever is missing, but by default, a call to createuser should
>> just run CREATE USER with default options.  The fact that createuser
>> issues prompts is always annoying when you create setup scripts, because
>> you have to be careful to specify all the necessary options, and they
>> are inconsistent and different between versions (although the last
>> change about that was a long time ago), and the whole behavior seems
>> contrary to the behavior of all other utilities.  I don't think there'd
>> be a real loss by not prompting by default; after all, we don't really
>> want to encourage users to create more superusers, do we?  Comments?
>
> Patch attached.  I'll add it to the next commitfest.

I looked at this patch for the 2012-01 CF. I like the idea, the
interactive-by-default behavior of createuser has always bugged me as
well.

I see this patch includes a small change to dropuser, to make the
'username' argument mandatory if --interactive is not set, for
symmetry with createuser's new behavior. That's dandy, though IMO we
shouldn't have "-i" be shorthand for "--interactive" with dropuser,
and something different with createuser (i.e. we should just get rid
of the "i" alias for dropuser).

Another little inconsistency I see with the behavior when no username
to create or drop is given:

$ createuser
createuser: creation of new role failed: ERROR: role "josh" already exists
$ dropuser
dropuser: missing required argument role name
Try "dropuser --help" for more information.

i.e. createuser tries taking either $PGUSER or the current username as
a default user to create, while dropuser just bails out. Personally, I
prefer just bailing out if no create/drop user is specified, but
either way I think they should be consistent.

Oh, and I think the leading whitespace of this help message:

printf(_(" --interactive prompt for missing role name
and attributes rather\n"

should be made the same as for other commands with no short-alias, e.g.

printf(_(" --replication role can initiate replication\n"));

Other than those little complaints, everything looks good.

Josh

On sön, 2012-01-15 at 18:14 -0500, Josh Kupershmidt wrote:
> I see this patch includes a small change to dropuser, to make the
> 'username' argument mandatory if --interactive is not set, for
> symmetry with createuser's new behavior. That's dandy, though IMO we
> shouldn't have "-i" be shorthand for "--interactive" with dropuser,
> and something different with createuser (i.e. we should just get rid
> of the "i" alias for dropuser).

Well, all the other tools also support -i for prompting. I'd rather get
rid of -i for --inherit, but I fear that will break things as well. I'm
not sure what to do.
>
> Another little inconsistency I see with the behavior when no username
> to create or drop is given:
>
> $ createuser
> createuser: creation of new role failed: ERROR: role "josh" already
> exists
> $ dropuser
> dropuser: missing required argument role name
> Try "dropuser --help" for more information.
>
> i.e. createuser tries taking either $PGUSER or the current username as
> a default user to create, while dropuser just bails out. Personally, I
> prefer just bailing out if no create/drop user is specified, but
> either way I think they should be consistent.

That is intentional long-standing behavior. createdb/dropdb work the
same way.

On Wed, Feb 1, 2012 at 1:13 PM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> On sön, 2012-01-15 at 18:14 -0500, Josh Kupershmidt wrote:
>> I see this patch includes a small change to dropuser, to make the
>> 'username' argument mandatory if --interactive is not set, for
>> symmetry with createuser's new behavior. That's dandy, though IMO we
>> shouldn't have "-i" be shorthand for "--interactive" with dropuser,
>> and something different with createuser (i.e. we should just get rid
>> of the "i" alias for dropuser).
>
> Well, all the other tools also support -i for prompting.

Taking a look at the current ./src/bin/scripts executables, I see only
2 out of 9 (`dropdb` and `dropuser`) which have "-i" mean
"--interactive", and `reindexdb` has another meaning for "-i"
entirely. So I'm not sure there's such a clear precedent for having
"-i" mean "--interactive" within our scripts, at least.

> I'd rather get
> rid of -i for --inherit, but I fear that will break things as well.  I'm
> not sure what to do.

I think breaking backwards compatibility probably won't fly (and
should probably be handled by another patch, anyway). I guess it's OK
to keep the patch's current behavior, given we are already
inconsistent about what "-i" means.

>> i.e. createuser tries taking either $PGUSER or the current username as
>> a default user to create, while dropuser just bails out. Personally, I
>> prefer just bailing out if no create/drop user is specified, but
>> either way I think they should be consistent.
>
> That is intentional long-standing behavior.  createdb/dropdb work the
> same way.

OK.

Josh