Re: UPDATE of partition key

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)com>, Greg Stark <stark(at)mit(dot)edu>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: UPDATE of partition key
Date: 2017-02-24 14:57:56
Message-ID: CAKFQuwZAVR5As9sbZm0PpUX4NfOA+EV9_dX6V668KtxYCKKrFA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Friday, February 24, 2017, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>
> 2. I know that DB2 handles this by having the user specify WITH ROW
> MOVEMENT to explicitly indicate they accept the issue and want update
> to work even with that. We could have an explicit option to allow
> that. This appears to be the only way we could avoid silent errors for
> foreign table partitions.
>
>
This does, however, make the partitioning very non-transparent to every
update query just because it is remotely possible a partition-moving update
might occur concurrently.

I dislike an error. I'd say that making partition "just work" here is
material for another patch. In this one an update of the partition key can
be documented as shorthand for delete-returning-insert with all the
limitations that go with that. If someone acceptably solves the
ctid following logic later it can be committed - I'm assuming there would
be no complaints to making things just work in a case where they only sorta
worked.

David J.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dilip Kumar 2017-02-24 15:45:50 Re: utility commands benefiting from parallel plan
Previous Message Andrew Dunstan 2017-02-24 14:48:30 Re: btree_gin and btree_gist for enums