From: | Karel Zak - Zakkr <zakkr(at)zf(dot)jcu(dot)cz> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] Re: [PATCHES] NO-CREATE-TABLE and NO-LOCK-TABLE |
Date: | 2000-02-29 10:38:52 |
Message-ID: | Pine.LNX.3.96.1000229103347.8101A-100000@ara.zf.jcu.cz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 29 Feb 2000, Peter Eisentraut wrote:
> 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.
Agree (Why is it not in TODO?). Do you work on this?
> 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
Here I not agree. I need users account with read-only/non-lock access. Very
simple is say "..not to use the database..", but you not "remake" my users,
you not admin for these users .. :-)
My NOLOCK implementation disallow LOCK TABLE command only, it not change
a low-level locking management.
> 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.
The grant/revoke is good, but it is not global setting.
The PostgreSQL needs more options/settings for administration, a current
features is very unsatisfactory for real using for large and multiuser
aplication.
My suggestion for PG's priv./accounts:
1/ global setting which overwrite local (acl) settings
- read-only account
- disable account (oracle: ACCOUNT LOCK)
- create table priv.
- user's quotas (but without tablespace?)
2/ spit current super-user privileges to
- (dis)allow create functions/opretors/trigers
- (dis)allow create user
? (dis)allow change system tables
3/ ? - remove current hda.conf to system catalogs
4/ user profiles
- CONNECT_TIME
- IDLE_TIME
- PASSWORD_LIFE_TIME
- PASSWORD_VERIFY_FUNCTION (trust/password/kerberos..)
- ..etc
(- CPU SPENTING ?)
5/ acl mask - default privilege for new table
Karel
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 2000-02-29 10:41:20 | Re: [HACKERS] Re: ALTER TABLE DROP COLUMN |
Previous Message | Jan Wieck | 2000-02-29 10:31:13 | Re: [HACKERS] Re: ALTER TABLE DROP COLUMN |