| From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Noah Misch <noah(at)leadboat(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: foreign key locks, 2nd attempt |
| Date: | 2012-02-23 18:41:21 |
| Message-ID: | CA+U5nML3f8Gvuk0diaOEHorG+GbKmwkHiy2Pafp7drbJFxZU9A@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Feb 23, 2012 at 4:01 PM, Alvaro Herrera
<alvherre(at)commandprompt(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kevin Grittner | 2012-02-23 18:44:50 | Re: foreign key locks, 2nd attempt |
| Previous Message | Greg Smith | 2012-02-23 18:30:09 | Re: foreign key locks, 2nd attempt |