From: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
---|---|
To: | giuseppe(at)eppesuigoccas(dot)homedns(dot)org |
Cc: | Jeff Hubbach <jeff(dot)hubbach(at)cha(dot)com>, pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: Transaction atomicity |
Date: | 2007-03-07 16:36:44 |
Message-ID: | 45EEEA1C.5050105@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
Jeff Hubbach wrote:
> Why not have a compound key on this table, with an ID generated by a
> sequence (one sequence, named the same, for each instance of PostgreSQL for
> each office), and an Office ID that is static for each instance? Then the
> merge/sync would go through without a hitch.
That's what I was thinking.
If you don't want to have a two-field key, for example because you can't
change the schema you already have, you could still divide a range of
ids for each office when you create the sequence:
CREATE SEQUENCE fooseq MINVALUE 10000000 MAXVALUE 19999999 NO CYCLE
Just use a different range for each office.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Giuseppe Sacco | 2007-03-07 16:39:00 | Re: Transaction atomicity |
Previous Message | Jeff Hubbach | 2007-03-07 16:25:51 | Re: Transaction atomicity |