Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1a8fDL-0004Pa-3Q for pgsql-docs@arkaria.postgresql.org; Tue, 15 Dec 2015 02:19:43 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1a8fDK-0001pY-AL for pgsql-docs@arkaria.postgresql.org; Tue, 15 Dec 2015 02:19:42 +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) (envelope-from ) id 1a8fCy-0001Rq-DT for pgsql-docs@postgresql.org; Tue, 15 Dec 2015 02:19:20 +0000 Received: from mail-wm0-x232.google.com ([2a00:1450:400c:c09::232]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84) (envelope-from ) id 1a8fCr-0003bI-02 for pgsql-docs@postgresql.org; Tue, 15 Dec 2015 02:19:19 +0000 Received: by mail-wm0-x232.google.com with SMTP id p66so70963794wmp.0 for ; Mon, 14 Dec 2015 18:19:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=RoRLfITCulZj3GNjO8qT3iD3qDeqGHMX3jBO/Q1/aBo=; b=0iHslvFKxzn0R6zhGMveKRxX9Qb4cCwzzETKr8O6DtBMkPiA/3NSzqiSDmXVmLfMf+ RwUq17GcSpKBynZxt4TrPVnrKxbzULjmcBVsjlY/xr3Pf2BuGnzVzazhW4MLYz5th/AJ hVosuTRcBPUroOcxzhjnAwLY3rO1AOHCk8HNLz2/beUGB6iMtLegM3TaNbwI/+Qykqrg F6qPVrPBP7OYFGltPcUPTZX1d8PRaUc6MJkrxKUdcEJ1f6021wkyYRJs/ZFJZOa3ROvO 6eY+tl7Ml2G1NyznD3AKFNgnFe4frpSH5yOo4qefKcwrS1MRB5byGaWA08m9U+LeAO2p lRig== X-Received: by 10.194.222.104 with SMTP id ql8mr47867424wjc.157.1450145950987; Mon, 14 Dec 2015 18:19:10 -0800 (PST) Received: from [192.168.2.3] (2-230-140-245.ip202.fastwebnet.it. [2.230.140.245]) by smtp.gmail.com with ESMTPSA id 186sm547957wmv.9.2015.12.14.18.19.09 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 14 Dec 2015 18:19:10 -0800 (PST) From: Pietro Pugni Content-Type: multipart/alternative; boundary="Apple-Mail=_E07DC8ED-CA9B-4BFF-AF32-52AC20DBE3E4" Subject: Let's improve the documentation of upper() Message-Id: Date: Tue, 15 Dec 2015 03:19:08 +0100 To: pgsql-docs@postgresql.org Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) X-Pg-Spam-Score: -2.7 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-docs Precedence: bulk Sender: pgsql-docs-owner@postgresql.org --Apple-Mail=_E07DC8ED-CA9B-4BFF-AF32-52AC20DBE3E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, I suggest to improve the documentation related to the upper() function = for discrete sets. It should be useful to report some examples using discrete type ranges = like datarange or int8range. I found this discussion on the bug mailing list: = http://www.postgresql.org/message-id/20150116152713.2582.10294@wrigleys.po= stgresql.org = It states that the mathematical definition used for upper bound is = actually wrong for discrete sets when explicitly defining ranges as = closed sets and I agree. I was working a lot with dates when I first found this =E2=80=9Cbug=E2=80=9D= . Users as me expect that upper(=E2=80=98[1,2]=E2=80=99::int8range) = returns 2 but it doesn=E2=80=99t. =46rom the documentation it=E2=80=99s = hard to find why PostgreSQL returns 3 instead of 2, so an example with a = brief and mathematically clear explanation should be provided (the = explanation provided is not clear at all). Also, from the answers given in the link above I suspect that this = function will be never modified to work as expected but I would like to = ask if it could be done in the near future. As for now the only way to return the actual mathematical upper bound of = a discrete range is to change if from being right closed to right = opened. This will return the expected value: SELECT upper(=E2=80=98[1,2)=E2=80=99::int8range) but this is more a hack than a real solution because that range should = contain only the number 1. Given integer numbers, the interval [1,2) = translates to {1} but what the user really wants is {1,2}. Again, the = upper bound of {1} is 1 while the upper bound of {1,2} is 2. The definition described in the documentation also contrasts with the = lower() function. Users like me expect a similar behavior for this = function, but it doesn=E2=80=99t and instead is mathematically correct. Regards Pietro Pugni --Apple-Mail=_E07DC8ED-CA9B-4BFF-AF32-52AC20DBE3E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi = all,
I suggest to improve the documentation related to the upper() = function for discrete sets.
It should be = useful to report some examples using discrete type ranges like datarange = or int8range.

I found this discussion on the bug mailing list: http://www.postgresql.org/message-id/20150116152713.2582.10294@= wrigleys.postgresql.org
It states that the = mathematical definition used for upper bound is actually wrong for = discrete sets when explicitly defining ranges as closed sets and I = agree.
I was working a lot with dates when I first = found this =E2=80=9Cbug=E2=80=9D.

Users as me expect that = upper(=E2=80=98[1,2]=E2=80=99::int8range) returns 2 but it doesn=E2=80=99t= . =46rom the documentation it=E2=80=99s hard to find why PostgreSQL = returns 3 instead of 2, so an example with a brief and mathematically = clear explanation should be provided (the explanation provided is not = clear at all).

Also, from the answers given in the link above I suspect that = this function will be never modified to work as expected but I would = like to ask if it could be done in the near future.

As for now the only way = to return the actual mathematical upper bound of a discrete range is to = change if from being right closed to right opened. This will return the = expected value:
SELECT = upper(=E2=80=98[1,2)=E2=80=99::int8range)
but this = is more a hack than a real solution because that range = should contain only the number 1. Given integer numbers,  the = interval [1,2) translates to {1} but what the user really wants is = {1,2}. Again, the upper bound of {1} is 1 while the upper bound of {1,2} = is 2.

The = definition described in the documentation also contrasts with the = lower() function. Users like me expect a similar behavior for this = function, but it doesn=E2=80=99t and instead is mathematically = correct.


Regards
 Pietro= Pugni

= --Apple-Mail=_E07DC8ED-CA9B-4BFF-AF32-52AC20DBE3E4--