From: | Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> |
---|---|
To: | Richard Huxton <dev(at)archonet(dot)com> |
Cc: | "Eric D(dot) Nielsen" <nielsene(at)mit(dot)edu>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Advice on merging two primary keys... |
Date: | 2005-06-29 12:39:00 |
Message-ID: | 20050629053336.F48334@megazone.bigpanda.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Wed, 29 Jun 2005, Richard Huxton wrote:
> Eric D. Nielsen wrote:
> > I've come into a situation where I will often need to merge two primary
> > keys, with numerous foreign keys hanging off of them. For instance:
>
> > While any update of the either primary key will cascade to all relevant
> > tables, such an update is disallowed for uniqueness reasons.
> >
> > Is there a good SQL-base method to accomplish this type of merging or
> > does this need application logic?
>
> It's irritating, because (afaict) the main use for cascading updates to
> a primary key is for merging. But, without deferred uniqueness checks
> you'll encounter the problem you mention. PG doesn't allow deferred
> uniqueness checks at the moment, so I'm afraid you'll have to explicitly
> update all the dependant tables.
Deferrable unique constraints probably wouldn't actually help because you
cannot refer a foreign key to a deferred unique constraint. (SQL92
11.8SR3) "The table constraint descriptor describing the <unique
constraint definition> whose <unique column list> identifies the
referenced columns shall indicate that the unique constraint is not
deferrable."
From | Date | Subject | |
---|---|---|---|
Next Message | Sven Willenberger | 2005-06-29 13:01:28 | PostgreSQL's vacuumdb fails to allocate memory for non-root users |
Previous Message | Michael Glaesemann | 2005-06-29 12:02:17 | Re: truncate all tables? |