Subject: CREATE USER

From: Jaime Casanova <[email-masked]>
Date: Fri, 9 Dec 2011 16:09:25 -0500

Hi,

I just notice that when you create a user using CREATE USER and give
the user the ability to create other users it gets created as
SUPERUSER. CREATE ROLE behaves as expected.

Looking at src/backend/parser/gram.y seems it's intentional, for
backwards compatibility. But the docs says:
"""
CREATE USER is now an alias for CREATE ROLE. The only difference is
that when the command is spelled CREATE USER, LOGIN is assumed by
default, whereas NOLOGIN is assumed when the command is spelled CREATE
ROLE.
"""

So, at least, we need to update docs or is undocumented intentionally
too? also i really think the command should raise a WARNING so we now
what's happening

-- 
Jaime Casanova         www.2ndQuadrant.com
Professional PostgreSQL: Soporte 24x7 y capacitación

---

From: Tom Lane <[email-masked]>
Date: Fri, 09 Dec 2011 22:21:17 -0500

Jaime Casanova <[email-masked]> writes:
> SUPERUSER.

Are you talking about the CREATEUSER option?  That is documented, quite
clearly I think:

	CREATEUSER
	NOCREATEUSER

	These clauses are an obsolete, but still accepted, spelling of
	SUPERUSER and NOSUPERUSER. Note that they are not equivalent to
	CREATEROLE as one might naively expect!

The only way we could really make this any better is to remove these
keywords, which might be something to consider.  The preferred SUPERUSER
spelling has been accepted since 8.1 ... is that long enough to ensure
everyone's converted their client-side tools?  Probably not :-(

			regards, tom lane

---

From: Jaime Casanova <[email-masked]>
Date: Fri, 9 Dec 2011 22:36:28 -0500

> Are you talking about the CREATEUSER option?  That is documented, quite

yes, i was. and it's seems you're right is documented... obviously i
was looking at the wrong place

> everyone's converted their client-side tools?  Probably not :-(

6 years since enough for me... actually i have been around even before
that and didn't remember that.
even if you think is not worth remove these, even a WARNING should be good

---

From: Scott Marlowe <[email-masked]>
Date: Sat, 10 Dec 2011 10:33:40 -0700

> even if you think is not worth remove these, even a WARNING should be good

Make sure the docs mention this and then remove it in the next major
release?  Works for me.

---

From: Bruce Momjian <[email-masked]>
Date: Tue, 13 Dec 2011 18:36:27 -0500 (EST)

> everyone's converted their client-side tools?  Probably not :-(

How does this relate to people restoring pre-8.1 pg_dumpall dumps? 
Seems removing this option would cause the restore to fail.

-- 
  Bruce Momjian  <[email-masked]>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +

---

From: Scott Marlowe <[email-masked]>
Date: Tue, 13 Dec 2011 17:12:07 -0700

> Seems removing this option would cause the restore to fail.

True, but 1: that's a really old release, and you should always dump
from the version you're going to not, going from, and 2: If you dumped
with 8.1 from 8.1 you're likely to have plenty of other issues loading
into later versions as well.  How about it's marked as deprecated to
be removed in the next major release (9.1) and removed the one after
that (9.2)?

---

From: Bruce Momjian <[email-masked]>
Date: Tue, 13 Dec 2011 20:39:14 -0500 (EST)

Scott Marlowe wrote:
> >> Are you talking about the CREATEUSER option? ?That is documented, quite
> >> clearly I think:
> >>
> >> ? ? ? CREATEUSER
> >> ? ? ? NOCREATEUSER
> >>
> >> ? ? ? These clauses are an obsolete, but still accepted, spelling of
> >> ? ? ? SUPERUSER and NOSUPERUSER. Note that they are not equivalent to
> >> ? ? ? CREATEROLE as one might naively expect!
> >>
> >> keywords, which might be something to consider. ?The preferred SUPERUSER
> >> everyone's converted their client-side tools? ?Probably not :-(
> >

Well, I know we support the new pg_dump dumping back to 7.1, but I don't
know what our policy is for accepting old dumps.

---

From: Tom Lane <[email-masked]>
Date: Tue, 13 Dec 2011 23:27:37 -0500

> know what our policy is for accepting old dumps.

We're still going to very large lengths to load pre-7.3 dumps; see
for instance ConvertTriggerToFK() in trigger.c.  I'm not aware of any
policy that would suggest blowing off pre-8.1 dumps should be
acceptable.  Yeah, it's true that the *recommended* procedure is to
use the newer pg_dump, but people aren't always in a position to do
that.

I think it might be sane to emit a WARNING suggesting that CREATEUSER
might not mean what you think, but failing is probably not good.

			regards, tom lane

---

From: Scott Marlowe <[email-masked]>
Date: Wed, 14 Dec 2011 00:14:49 -0700

> might not mean what you think, but failing is probably not good.

I guess there's really no reason to get rid of it, just drop it from
that part of the docs, mark is as deprecated?

---

From: Jaime Casanova <[email-masked]>
Date: Tue, 24 Apr 2012 01:55:19 -0500

> might not mean what you think, but failing is probably not good.

are we going to do this in this release?
i never was able to think in a good phrasing for this, though

---

From: Robert Haas <[email-masked]>
Date: Wed, 2 May 2012 13:09:39 -0400

> i never was able to think in a good phrasing for this, though

I actually think we should just leave this alone.  There is a
limitless number of things that someone could potentially be confused
by if they fail to read the documentation, and we can't warn about all
of them.

Now, one thing we could do is add a deprecation warning, stating that
CREATEUSER may be removed in a future release, assuming we want to
eventually remove it.  But I don't think warning people that
CREATEUSER means SUPERUSER and not CREATEROLE is very helpful.

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

---

From: Jaime Casanova <[email-masked]>
Date: Thu, 3 May 2012 14:05:49 -0500

> by if they fail to read the documentation, and we can't warn about all

maybe is not very helpful, but it can't hurt... hey! it can save you
because you maybe used CREATEUSER with the intention of CREATEROLE,
and ended up with a user with restricted privileges that is actually a
SUPERUSER... that's bad and is a POLA violation.

is worse because we are the ones causing the confusion consider the syntax:
CREATE USER = CREATE ROLE
IN GROUP = IN ROLE
USER = ROLE

CREATEUSER != CREATEROLE
CREATEUSER = SUPERUSER

---

From: Bruce Momjian <[email-masked]>
Date: Wed, 29 Aug 2012 21:14:40 -0400

> CREATE USER = CREATE ROLE

I looked at this and can't see a way to make CREATEUSER != CREATEROLE
clearer:

   The only difference is that when the command is spelled CREATE USER,
   LOGIN is assumed by default, whereas NOLOGIN is assumed when the
   command is spelled CREATE ROLE.