| From: | Steven Brown <swbrown(at)ucsd(dot)edu> |
|---|---|
| To: | Tino Wildenhain <tino(at)wildenhain(dot)de> |
| Cc: | kleptog(at)svana(dot)org, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Enforcing serial uniqueness? |
| Date: | 2006-03-22 14:13:37 |
| Message-ID: | 44215B91.4080405@ucsd.edu |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Tino Wildenhain wrote:
> since your insert above would call nextval() per default,
> its save to use currval() in the same transaction.
Ah, I didn't realize currval() was handled session-local - that removes
my need to support any non-default value to my serial column. So, if I
can identify use of a non-default value via a trigger, that solves my
first problem. I'll try writing such a trigger tomorrow.
That leaves only preventing use of setval() as a problem. If I revoke
UPDATE, it also blocks the use of nextval() by the default value for the
serial column on INSERT.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2006-03-22 14:23:04 | Re: Enforcing serial uniqueness? |
| Previous Message | Tom Lane | 2006-03-22 14:12:27 | Re: invalid page header |