From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Aasmund Midttun Godal" <postgresql(at)envisity(dot)com> |
Cc: | pgsql-sql(at)postgresql(dot)org |
Subject: | Re: Sequence permission suggestion |
Date: | 2001-11-26 01:19:22 |
Message-ID: | 7249.1006737562@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
"Aasmund Midttun Godal" <postgresql(at)envisity(dot)com> writes:
> Today it seems that the following rules governs the permissions of sequences:
> SELECT - allow you to select * from seq_name;
> INSERT - no effect
> UPDATE - allows nextval, setval - and yes implicitly currval
> DELETE - no effect
> I suggest nextval is moved into the insert permission as this is quite
> natural
It looks like an update to me; in particular, it allows you to determine
the old state of the sequence, and thus has read+write semantics not
only write semantics.
> normally you only need to call nextval when you insert a new value
> into a table. I think this issue is important because setting the
> sequence to a value lower than the max value in a table will cause
> errors for other users.
This seems to be exceedingly SERIAL-centric thinking; there are other
uses for sequences than serials.
It might make sense to allow either INSERT or UPDATE permission to
grant nextval() access, while still requiring UPDATE for setval().
But I'm not convinced yet ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | cnliou | 2001-11-26 01:40:53 | Exception When Insert Followed By Delete In PL/PGSQL |
Previous Message | Aasmund Midttun Godal | 2001-11-26 00:55:14 | Sequence permission suggestion |