From: | Steven Brown <swbrown(at)ucsd(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Changing ids conflicting with serial values? |
Date: | 2005-11-03 03:29:10 |
Message-ID: | 43698406.4010008@ucsd.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Tom Lane wrote:
> Steven Brown <swbrown(at)ucsd(dot)edu> writes:
>> When I change an id (primary key serial) in a table, the next value
>> returned by the sequence for the id can conflict with that id (e.g.,
>> change the id to be id + 1).
[...]
> Plan A: don't do that. Why in the world is it a good idea to modify an
> artificial primary key? It's not like there's some external meaning to
> the values.
I'm granting access to insert/update/delete rows of a table to people,
but I don't want all future inserts to fail if they decided to change an
id (which they obviously shouldn't, but they /can/). It makes for a
fragile system.
Should I just be using some sort of trigger to block them from modifying
the id, or is there another way to handle it? I.e., how do people
normally handle that? It's a migration thing - MySQL prevented this
situation due to the way it handles auto_increment (it will never assign
you an id that already exists).
From | Date | Subject | |
---|---|---|---|
Next Message | Douglas McNaught | 2005-11-03 03:47:20 | Re: Changing ids conflicting with serial values? |
Previous Message | David Gagnon | 2005-11-03 03:19:53 | Problem with array in plpgsql function .. please help :-) |