Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qOXSz-008A3b-3x for pgsql-docs@arkaria.postgresql.org; Wed, 26 Jul 2023 05:53:45 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1qOXSx-002X2U-CM for pgsql-docs@arkaria.postgresql.org; Wed, 26 Jul 2023 05:53:43 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qOXSx-002X2H-18 for pgsql-docs@lists.postgresql.org; Wed, 26 Jul 2023 05:53:43 +0000 Received: from mail-wm1-x344.google.com ([2a00:1450:4864:20::344]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1qOXSu-001clV-5u for pgsql-docs@lists.postgresql.org; Wed, 26 Jul 2023 05:53:41 +0000 Received: by mail-wm1-x344.google.com with SMTP id 5b1f17b1804b1-3fb4146e8deso64494145e9.0 for ; Tue, 25 Jul 2023 22:53:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybertec-at.20221208.gappssmtp.com; s=20221208; t=1690350818; x=1690955618; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:to:from:subject:message-id:from:to:cc:subject:date :message-id:reply-to; bh=msbSaIKr/tACep0PuH7tXssZIsMxtDHF09cGs/Qv1mA=; b=eXhyNhigT0yVNTJNTVDn6Z9wi2n4T+Ogn2QXLWGaL0pkVpCs3F8kuqI00ftQ1EfQfF WTQLiBD9saCliht2lULos4c5QaillYDatys0/1yJevb0Py2kj5hmNVNWN7nVzAyGYEOy g5a3COxhDORFhsxN/mAYDZfciITw2gZ3DKWGdJYhC7nTWo2ZRIoeV3KAFZcjbO1+U/ap Eel+Ad+k6SgmgVZggqRz6ccgBRTUg5hGVhKPbXn4GBrYjom0TL5WtKaHxK8wsIuKbA6H OgkLqy+b8W/B5zutAupWok3/27jYxdYV7LJtxretJ0nQIpiYld2ARa+SOdxcvlfrDqFJ kU5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690350818; x=1690955618; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:to:from:subject:message-id:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=msbSaIKr/tACep0PuH7tXssZIsMxtDHF09cGs/Qv1mA=; b=MAvzl4EmjoO8IBxCyBObYoDyYuhUlm8ZOrmMpmSfmSTDVf13MNePEfogKyqM65nB0M kB4U3jne9flAQ9V7K9D3O/rngT/cxPMIql7j44+nupln+VrLSWT/DfmKgzoqImGxhURF tUTT6ZtcUNjh/Ma/MUcEnfP1eBFpZBJbJQBuuzaimQvw8WvqbVVVM07X2SKhfWY9kzIU dZcb7p3MtfTwrs2agCLCz7wFwnDkneE5kfvqvDieztu5ndn8yRre7NBELlnHtNmtRZra xlGUoVpInP2OncE/FvfwXScU9fZtQUW/N1T8FzzjtSrtcp14G7dDkUEmVzm6Ozmq2Ayu mPnw== X-Gm-Message-State: ABy/qLY+SjOYWqrc8+87v4wfUMhVwF8XFkneHVsIOb2IBg6oorLmXyW4 A+axT/CU0RdT8pO1Ns9ZV26bqg== X-Google-Smtp-Source: APBJJlFNQjDS1/v5Kf1weiuUgyFKWZA1Rrvz0DCU0QAZo7iRIFhHmanFTg/hyutXtS1XsjwqI+2qRg== X-Received: by 2002:a05:600c:2946:b0:3f5:fff8:d4f3 with SMTP id n6-20020a05600c294600b003f5fff8d4f3mr543155wmd.7.1690350817806; Tue, 25 Jul 2023 22:53:37 -0700 (PDT) Received: from localhost.localdomain ([41.66.96.96]) by smtp.gmail.com with ESMTPSA id 18-20020a05600c235200b003fc3b03e41dsm3889164wmq.0.2023.07.25.22.53.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 25 Jul 2023 22:53:37 -0700 (PDT) Message-ID: Subject: Re: to_char(numeric type, text) rounding instead of truncating From: Laurenz Albe To: barsikdacat@gmail.com, pgsql-docs@lists.postgresql.org Date: Wed, 26 Jul 2023 07:53:36 +0200 In-Reply-To: <168991536429.626.9957835774751337210@wrigleys.postgresql.org> References: <168991536429.626.9957835774751337210@wrigleys.postgresql.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4 (3.46.4-1.fc37) MIME-Version: 1.0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Fri, 2023-07-21 at 04:56 +0000, PG Doc comments form wrote: > The following documentation comment has been logged on the website: >=20 > Page: https://www.postgresql.org/docs/15/functions-formatting.html > Description: >=20 > I've encountered an issue with to_char(numeric type, text) > Apparently, it uses rounding instead of truncation which leads to > unpexpected results. This is not reflected in the documentation. > My specific example: > select to_Char(1235::real/(2::real+1235::real)*100, '99%') > The expected output was 99%. The output was ##% - since the number was > rounded to 100, there wasn't enough digits in the format. > If I add a digit after the decimal point > select to_char(1235::real/(2::real+1235::real)*100,'90D0%') > The output becomes 99.8% >=20 > It would be nice to have this behavior explained in the documentation so > people get more predictable results. +1 How about the following: diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml index 5a47ce4343..9421ace77e 100644 --- a/doc/src/sgml/func.sgml +++ b/doc/src/sgml/func.sgml @@ -8505,6 +8505,14 @@ SELECT regexp_match('abc01234xyz', '(?:(.*?)(\d+)(.*= )){1,1}'); =20 + + + If the format provides for fewer fractional digits than the number = being + formatted has, to_char() will round the number= to + the specified number of fractional digits. + + + The pattern characters S, L, = D, Yours, Laurenz Albe