Re: inherited, unique serial field...
Will Trillich <will@serensoft.com>
From: will trillich <will@serensoft.com>
To: pgsql-general@postgresql.org
Date: 2003-02-08T05:53:50Z
Lists: pgsql-general
On Fri, Feb 07, 2003 at 08:50:38AM -0800, Chris Travers wrote: > will trillich wrote: > >is it bad news to have id collisions when you use an > >inherited serial field? > > > I am still having trouble determining what is going on in your > example (where does the 4 come from?) but I can see where you > might see some problems if you were trying to preserve > referential integrity to the parent table. the 4 was just a sample (duplicate) id. the child tables are each consistent with their unique constraints -- but the parent table, which has a unique constraint (primary key!) as well, turns out to have duplicates in the key field ( id in this example ). create table track ( id serial, created date default current_date, primary key ( id ) ); create table <yada> (...) inherits ( track ); -- inserts & sech on child tables, including id values SELECT t.id, t.created, c.relname AS class FROM track t, pg_class c WHERE t.id = 2 AND (t.tableoid = c.oid); id | created | class ----+------------+---------- 4 | 2003-02-06 | other 4 | 2003-02-06 | person > Yes, I would avoid this problem. i think it's wise, too, but i haven't run into any debilitating circumstances because of this. yet. i wondered if i was lucky or if it's really no big deal. -- There are 10 kinds of people: ones that get binary, and ones that don't. will@serensoft.com http://sourceforge.net/projects/newbiedoc -- we need your brain! http://www.dontUthink.com/ -- your brain needs us! Looking for a firewall? Do you think smoothwall sucks? You're probably right... Try the folks at http://clarkconnect.org/ !