Re: foreign key locks, 2nd attempt
Simon Riggs <simon@2ndquadrant.com>
From: Simon Riggs <simon@2ndQuadrant.com>
To: Alvaro Herrera <alvherre@commandprompt.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Noah Misch <noah@leadboat.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2012-02-23T18:41:21Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Try to avoid running with a full fsync request queue.
- 7f242d880b5b 9.1.0 cited
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