Postgres Pro
Downloads
Home   >   mailing lists

Thread: RFC: create/alter user extension

RFC: create/alter user extension

From
Peter Eisentraut
Date:
Is everyone okay with the following syntax:

CREATE USER username
[ WITH ID digits ]
^^^^^^^^^^^^^^^^^^
[ WITH PASSWORD password ]
[ CREATEDB   | NOCREATEDB ]
[ CREATEUSER | NOCREATEUSER ]
[ IN GROUP     groupname [, ...] ]
[ VALID UNTIL  'abstime' ]

ALTER USER username
[ WITH ID digits ]
^^^^^^^^^^^^^^^^^^
[ WITH PASSWORD password ]
[ CREATEDB | NOCREATEDB ]
[ CREATEUSER | NOCREATEUSER ]
[ IN GROUP groupname [, ...] ]
[ VALID UNTIL 'abstime' ]

The catch is that ID would have to be a new keyword and we'd have to live
with that for a long time. Other choices include:
* UID
* SYSID
* USESYSID
etc.

What do the standards and pseudo-standards say?

I think I'll take a stab at this and settle the createuser script issue
the proper way.
-Peter

-- 
Peter Eisentraut                  Sernanders vaeg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden

Re: [HACKERS] RFC: create/alter user extension

From
Tom Lane
Date:
Peter Eisentraut <peter_e@gmx.net> writes:
> Is everyone okay with the following syntax:
> CREATE USER username
> [ WITH ID digits ]
> ^^^^^^^^^^^^^^^^^^

> The catch is that ID would have to be a new keyword and we'd have to live
> with that for a long time. Other choices include:
> * UID
> * SYSID
> * USESYSID
> etc.

I'd be inclined to go with UID or SYSID.  In any case, since the new
keyword is used in such a limited context, we could almost certainly
still allow it as a ColId and thus not create any real compatibility
problem.
        regards, tom lane

Re: [HACKERS] RFC: create/alter user extension

From
Peter Eisentraut
Date:
On Fri, 12 Nov 1999, Tom Lane wrote:

> Peter Eisentraut <peter_e@gmx.net> writes:
> > Is everyone okay with the following syntax:
> > CREATE USER username
> > [ WITH ID digits ]
> > ^^^^^^^^^^^^^^^^^^
> 
> > The catch is that ID would have to be a new keyword and we'd have to live
> > with that for a long time. Other choices include:
> > * UID
> > * SYSID
> > * USESYSID
> > etc.
> 
> I'd be inclined to go with UID or SYSID.  In any case, since the new
> keyword is used in such a limited context, we could almost certainly
> still allow it as a ColId and thus not create any real compatibility
> problem.

I'm not sure about this distinction. Where would that be reflected in the
(parser) code?
-Peter

-- 
Peter Eisentraut                  Sernanders vaeg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden

Re: [HACKERS] RFC: create/alter user extension

From
Tom Lane
Date:
Peter Eisentraut <e99re41@DoCS.UU.SE> writes:
>> I'd be inclined to go with UID or SYSID.  In any case, since the new
>> keyword is used in such a limited context, we could almost certainly
>> still allow it as a ColId and thus not create any real compatibility
>> problem.

> I'm not sure about this distinction. Where would that be reflected in the
> (parser) code?

You should try to add this (or any other) new keyword to the list in the
ColId: production in gram.y.  If that doesn't provoke any complaints
from yacc (shift/reduce conflicts etc), then you're home free: the
parser won't get confused if the keyword is used as a column name.

If it does cause a shift/reduce conflict, which is fairly likely for
anything that can appear inside an expression, you might still be
able to add the new keyword to the ColLabel: list.  That allows it
to be used as an identifier in a more restricted set of contexts.

Only if neither of these will work does the keyword need to be a
truly "reserved" word.
        regards, tom lane