Re: [PATCHES] NO-CREATE-TABLE and NO-LOCK-TABLE - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: [PATCHES] NO-CREATE-TABLE and NO-LOCK-TABLE
Date
Msg-id Pine.LNX.4.21.0002282246340.3511-100000@localhost.localdomain
Whole thread Raw
Responses Re: [HACKERS] Re: [PATCHES] NO-CREATE-TABLE and NO-LOCK-TABLE
List pgsql-hackers
Karel Zak - Zakkr writes:

> This patch add to current code NOCREATETABLE and NOLOCKTABLE feature:
> 
> CREATE USER username
>     [ WITH
>      [ SYSID uid ]
>      [ PASSWORD 'password' ] ]
>     [ CREATEDB   | NOCREATEDB ] [ CREATEUSER | NOCREATEUSER ]
> ->  [ CREATETABLE | NOCREATETABLE ] [ LOCKTABLE | NOLOCKTABLE ]
>     ...etc.

IMHO, the syntax for create user is a hell and a half. Adding more
keywords in the current fashion is a dead end. (Note: you have to remember
the order in which the user "features" have to be entered.)

I might as well propose that now, I'd like to see a syntax like

CREATE USER name (   password = 'xxx',   sysid = 99,   superuser = true,   ...
);

That's much more flexible and extensible. The old syntax could coexist
with this too.


Regarding your two new features:

If you disallow table locking you might as well tell users not to use the
database. People need locks to operate a relational database. You will end
up disabling the entire transaction mechanism if you want this to work
properly. There already is a sufficient amount of checks for users not
claiming exlusive locks on tables they shouldn't.

Disallowing table creation might seem like a decent idea, but if at all,
it should go into the grant/revoke realm. Incidentally, this is quite at
odds with the SQL idea of how things should work, and I had hoped we could
get there some day.


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



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] Beta for 4:30AST ... ?
Next
From: Tom Lane
Date:
Subject: Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)