| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Steven Brown <swbrown(at)ucsd(dot)edu> |
| Cc: | kleptog(at)svana(dot)org, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Enforcing serial uniqueness? |
| Date: | 2006-03-22 14:23:04 |
| Message-ID: | 16049.1143037384@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Steven Brown <swbrown(at)ucsd(dot)edu> writes:
> Martijn van Oosterhout wrote:
>> IIRC you can set the permissions on a sequence to allow nextval but not
>> setval.
> I've not been able to find a way - granting UPDATE grants the use of
> both.
Yes. This is intentional, on the grounds that being able to do NEXTVAL
enough times is equivalent to SETVAL. (Only strictly true for a CYCLE
sequence, but the point is that if you don't want to allow SETVAL you
shouldn't want to allow unrestricted use of NEXTVAL either.)
I think the solution for you is to use BEFORE triggers as suggested
upthread. The BEFORE INSERT trigger function should be SECURITY DEFINER
and owned by a user who has permission to NEXTVAL the sequence. The id
column should probably be declared plain integer (or bigint), not
SERIAL, because there's no percentage in setting a default that's just
going to be overwritten by the trigger.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2006-03-22 14:29:26 | Re: back slash separated values |
| Previous Message | Steven Brown | 2006-03-22 14:13:37 | Re: Enforcing serial uniqueness? |