Re: foreign key locks, 2nd attempt - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: foreign key locks, 2nd attempt
Date
Msg-id CA+U5nML3f8Gvuk0diaOEHorG+GbKmwkHiy2Pafp7drbJFxZU9A@mail.gmail.com
Whole thread Raw
In response to Re: foreign key locks, 2nd attempt  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
On Thu, Feb 23, 2012 at 4:01 PM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:

> As far as complexity, yeah, it's a lot more complex now -- no question
> about that.

As far as complexity goes, would it be easier if we treated the UPDATE
of a primary key column as a DELETE plus an INSERT?

There's not really a logical reason why updating a primary key has
meaning, so allowing an ExecPlanQual to follow the chain across
primary key values doesn't seem valid to me.

That would make all primary keys IMMUTABLE to updates.

No primary key, no problem.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


pgsql-hackers by date:

Previous
From: Greg Smith
Date:
Subject: Re: foreign key locks, 2nd attempt
Next
From: "Kevin Grittner"
Date:
Subject: Re: foreign key locks, 2nd attempt