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.
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 |