Re: pgsql: Doc: desultory copy-editing for v10 release notes.

From: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-committers(at)postgresql(dot)org
Subject: Re: pgsql: Doc: desultory copy-editing for v10 release notes.
Date: 2017-07-10 04:38:39
Message-ID: eaa04036-9729-b51d-4328-bd6d71a66985@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

On 2017/07/10 12:36, Tom Lane wrote:
> Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> writes:
>> On 2017/07/10 9:11, Tom Lane wrote:
>>> Doc: desultory copy-editing for v10 release notes.
>
>> I see you updated text for the partitioning item:
>
>> syntax</> that automatically creates partition constraints and
>> - <command>INSERT</> routing (Amit Langote)
>> + handles routing of tuple insertions and updates (Amit Langote)
>
>> Although I like the new text better, I'm afraid that we don't support
>> routing updates yet, only inserts.
>
> Hm? We correctly handle updates that don't change the partition key
> columns, as well as deletes, no?

That's true.

> The previous text made it sound like *only* the insert case worked properly.

So, as long as an UPDATE doesn't change the partition key of a tuple, it's
being "routed" correctly, that is, put back into the same partition.

To me, the phrase "routing updates" meant "re-routing" a tuple when the
partition key change requires it, but I may be wrong.

> It might be worth mentioning that you can't move a row into another
> partition via UPDATE. Or maybe that's more detail than we need here.
> Not sure.

Maybe, we can leave that detail out of the release notes.

Thanks,
Amit

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2017-07-10 04:44:46 pgsql: Doc: remove claim that PROVE_FLAGS defaults to '--verbose'.
Previous Message Tom Lane 2017-07-10 04:09:14 pgsql: Doc: clarify wording about tool requirements in sourcerepo.sgml.