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/ !