Re: Transaction atomicity - Mailing list pgsql-jdbc

From Heikki Linnakangas
Subject Re: Transaction atomicity
Date
Msg-id 45EEEA1C.5050105@enterprisedb.com
Whole thread Raw
In response to Re: Transaction atomicity  ("Jeff Hubbach" <jeff.hubbach@cha.com>)
Responses Re: Transaction atomicity  (Giuseppe Sacco <giuseppe@eppesuigoccas.homedns.org>)
List 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

pgsql-jdbc by date:

Previous
From: Giuseppe Sacco
Date:
Subject: Re: Transaction atomicity
Next
From: Giuseppe Sacco
Date:
Subject: Re: Transaction atomicity