Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1edYSb-0002G4-EZ for pgsql-docs@arkaria.postgresql.org; Mon, 22 Jan 2018 09:32:13 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1edYSa-0001AJ-RO for pgsql-docs@arkaria.postgresql.org; Mon, 22 Jan 2018 09:32:12 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1edYSa-0001AA-G6 for pgsql-docs@lists.postgresql.org; Mon, 22 Jan 2018 09:32:12 +0000 Received: from mail-it0-x244.google.com ([2607:f8b0:4001:c0b::244]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1edYSX-0002iw-Lz for pgsql-docs@lists.postgresql.org; Mon, 22 Jan 2018 09:32:11 +0000 Received: by mail-it0-x244.google.com with SMTP id q8so9041820itb.2 for ; Mon, 22 Jan 2018 01:32:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EDTgwhkcEcEGZ9RBBrhMhU8LLlecPHKXYtH+OMSfq0c=; b=i594YtvRflaoGbaLZsjSM+gilTDeKfzqw+K/BPHujZ2DpuqKklGhZTesqFWCZ/hWQ+ JUYvuA/bzE6O0R3px/62X9FN5LMtkLtFV7i1d1zzwOokOiQDH7ze5KBcmwcNSHyJjGCK /fzZxRa//r7sU/M/A+B2aN5Gxzolm/5OxxFe6mZkm7svbBiO+MLC/k5UfRSh07wTvnx2 qjMVd26blyBp6yxm+88N6EASGNa3kr+QrJJRN5L9CwLBBcKQWr5Gkazdt8nyAMYDOaEP 8sJA8SpttCVEnjLxqnQNBfnyrbhN8fOiLWmTXF+t8E6MAn1BhrWHMCT0QCoR1KiUqW1q 775Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EDTgwhkcEcEGZ9RBBrhMhU8LLlecPHKXYtH+OMSfq0c=; b=CV9JGiFBTOmb3FSFEnMFkrZ/yStrfQcJ9EL9TuWeuJGZXoXzfzrAJ2FdGmopu6bjTb pHjsQL2zgaNsHQb/DLzXREgcYd/izhzGk1EpzDsm8NdRCCXAcs20rwLGaqDlCD1NAskU YO/uDOSFt4wDaow8dk2pVUhEAAXHMSDCuoS9kIJPGEdNr/D6/+Dr0xLC4NKb6yCY6nCW 7sRm/bXXIaxsgi5zTyme/s4BJ+Z+ELZ0M8dxwyPdvtHy7aay3bvO5i3acBb6DmGbpRVe A/lPyAD6AOcy6KT9CPYpX8Jo4kp7332Hxxdhpf/CBM2JvoeN5XBUVEzzWvGTeP2qgPxX 8vpQ== X-Gm-Message-State: AKwxytfU7nkyqTc0SmmBpfNXLGMVr3zX9N3Ux3bPIaxig3rRio3C7N1U ZV+YDPnXWDc8vHDcQMm+TfIWZflFprtTOb2IsK8= X-Google-Smtp-Source: AH8x2250ddqo3PSslgakRaGGii7QFcZ/wVuDx6GsxJDV3F4bQlfEURc39Xyci3NDJ+mv/e/LMk39CbWM/sZ9SngYSlY= X-Received: by 10.36.112.206 with SMTP id f197mr6623815itc.133.1516613528680; Mon, 22 Jan 2018 01:32:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.164.130 with HTTP; Mon, 22 Jan 2018 01:31:48 -0800 (PST) In-Reply-To: References: <20180120205832.3624.66654@wrigleys.postgresql.org> From: Pantelis Theodosiou Date: Mon, 22 Jan 2018 09:31:48 +0000 Message-ID: Subject: Re: overlapping ranges To: Nick Farrell Cc: Peter Eisentraut , pgsql-docs@lists.postgresql.org, PG Doc comments form Content-Type: multipart/alternative; boundary="001a113f76b8a37e5405635a1a77" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --001a113f76b8a37e5405635a1a77 Content-Type: text/plain; charset="UTF-8" The CREATE TABLE page has this explanation, about FROM and TO in partitioning declarations: > When creating a range partition, the lower bound specified with FROM is an inclusive bound, whereas the upper bound specified with TO is an exclusive bound. That is, the values specified in the FROM list are valid values of the corresponding partition key columns for this partition, whereas those in the TO list are not. On Sat, Jan 20, 2018 at 10:39 PM, Nick Farrell wrote: > Further down the page, that is contradicted, where there are numeric > ranges spaced every hundred, where it says that is disallowed because of > the ambiguity at the overlap point. Either way, the documentation is > inconsistent. > > On 21 Jan. 2018 9:26 am, "Peter Eisentraut" com> wrote: > >> On 1/20/18 15:58, PG Doc comments form wrote: >> > The following documentation comment has been logged on the website: >> > >> > Page: https://www.postgresql.org/docs/10/static/ddl-partitioning.html >> > Description: >> > >> > In the date partitioning example the first and last dates are the first >> of >> > the month, which will cause conflicts. The last date needs to be the >> final >> > day of the same month. >> >> I don't think so, because the upper bound of the range is not included >> in the range. >> >> -- >> Peter Eisentraut http://www.2ndQuadrant.com/ >> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services >> > --001a113f76b8a37e5405635a1a77 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The CREATE TABLE page has this explanation, about FROM and= TO in partitioning declarations:

> When creating a range partiti= on, the lower bound specified with FROM is an inclusive bound, whereas the upper bound specified with TO is an exclusive bound. That is, the values specified in the FROM list are valid values of the corresponding partition key columns for this partition, whereas those in the TO list are not.



On Sat, Jan 20, 2018 at 10:39 PM, Nick Farrell <nicholas.farrell@gmail.com> wrote:
Further down the page, that = is contradicted, where there are numeric ranges spaced every hundred, where= it says that is disallowed because of the ambiguity at the overlap point. = Either way, the documentation is inconsistent.

On 21 Jan. 2018 9:26 am, "Peter Eisentraut" <peter.eise= ntraut@2ndquadrant.com> wrote:
On 1/20/18 15:58, PG Doc comments= form wrote:
> The following documentation comment has been logged on the website: >
> Page: https://www.postgresql.org= /docs/10/static/ddl-partitioning.html
> Description:
>
> In the date partitioning example the first and last dates are the firs= t of
> the month, which will cause conflicts. The last date needs to be the f= inal
> day of the same month.

I don't think so, because the upper bound of the range is not included<= br> in the range.

--
Peter Eisentraut=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://w= ww.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--001a113f76b8a37e5405635a1a77--