Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jc0cq-00086t-5m for pgsql-hackers@arkaria.postgresql.org; Fri, 22 May 2020 05:53:44 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jc0cp-0003X5-1F for pgsql-hackers@arkaria.postgresql.org; Fri, 22 May 2020 05:53:43 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jc0co-0003Wf-Iw for pgsql-hackers@lists.postgresql.org; Fri, 22 May 2020 05:53:42 +0000 Received: from mail-pl1-x641.google.com ([2607:f8b0:4864:20::641]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jc0ck-0002AH-NA for pgsql-hackers@postgresql.org; Fri, 22 May 2020 05:53:42 +0000 Received: by mail-pl1-x641.google.com with SMTP id t16so3959119plo.7 for ; Thu, 21 May 2020 22:53:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leadboat.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=KfBWU//mK8pluDyl0nqxMti7z6ZYzBhm2EbGcbMHvm0=; b=R7vOdYN8oudpmjCcdYnfDAds7GW1okRXozZmyymahoPKnaTdU3O8SvsLD0aGt0t8v6 cgZFxsBobwCXRhzrz+j3KckejT7tEyfV+SwvciidVR8m18FYQzVdxp2b23Ct7PcN8Hce VJEPDuqfHPzbOm1FvPD00UhbVCDSppM1CTKoY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=KfBWU//mK8pluDyl0nqxMti7z6ZYzBhm2EbGcbMHvm0=; b=i35kJyzutUb0Dl/imM+6Am/wfMqIDPKf3lk1sdsHHhtxVkkyJ8IZFndKhajj5Q1oD2 o6EWNITNd6a1QyDdbesMhG9KkpTM+V/vPyiEZosD9bfmFcOzk2Oo4SW/nMINVJZZhnbK 9KoH0reC6ClHCRrsmmbPYP6lqYL6LDG4FZe0gOQZYZ+GL4mKfAZPnvwEfheyqUL1f7pm 7J9+Xm/GTbGFHF2V6R0JCFmVZHfyoJ89BfWcX3OWAGl31U3fClOEGqRZMFpUq6f9phji TBKEYsYtr39zs6NWBESABs6zkwwDcEyZPUL3I0T6oCv2FcUmUcX8AD6TnWn7BFV+16et EmEA== X-Gm-Message-State: AOAM533Lo7QP/X1gJ8Cn4WWfWy3gri7NWl1Ls4SylsPe47dWgbuiVeIN X7TOtVMqz/ueaOGgUq5P7zJpxg== X-Google-Smtp-Source: ABdhPJwm3K2spjpI9HM3wgyC4BzzgWttvxtYxYjFagCK11YwD7qBNrLX/SGMNICeyxvHTkhYh4WZBQ== X-Received: by 2002:a17:902:6ac2:: with SMTP id i2mr13492962plt.18.1590126816255; Thu, 21 May 2020 22:53:36 -0700 (PDT) Received: from rfd.leadboat.com (108-233-125-46.lightspeed.sntcca.sbcglobal.net. [108.233.125.46]) by smtp.gmail.com with ESMTPSA id p9sm5287446pgb.19.2020.05.21.22.53.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 May 2020 22:53:35 -0700 (PDT) Date: Thu, 21 May 2020 22:53:32 -0700 From: Noah Misch To: Robert Haas Cc: Tom Lane , Chapman Flack , Peter Eisentraut , Joe Nelson , "pgsql-hackers@postgresql.org" Subject: Re: POC: rational number type (fractions) Message-ID: <20200522055332.GA1296415@rfd.leadboat.com> References: <20200208042554.GE42864@begriffs.com> <0e2422da-953b-6b96-1900-f67c7e5e3307@2ndquadrant.com> <5EC3031C.6020105@anastigmatix.net> <20552.1589840076@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Thu, May 21, 2020 at 01:40:10PM -0400, Robert Haas wrote: > On Mon, May 18, 2020 at 6:15 PM Tom Lane wrote: > > There surely are use-cases for true rational arithmetic, but I'm > > dubious that it belongs in core Postgres. I don't think that enough > > of our users would want it to justify expending core-project maintenance > > effort on it. So I'd be happier to see this as an out-of-core extension. > > As is often the case, I'm a little more positive about including this > than Tom, but as is also often the case, I'm somewhat cautious, too. > On the one hand, I think it would be cool to have and people would > like it. But, On the other hand, I also think we'd only want it if > we're convinced that it's a really good implementation and that > there's not a competing design which is better, or even equally good. I vote for keeping it out of core, mostly because writing rational numeric code is so different from writing DBMS core code. (Many of our existing types, like numeric and the geometric types, have the same problem. Let's not invite more of that.) The optimal reviewer pools won't have much overlap, so patches may sit awhile and/or settle for a cursory review. More language standard libraries provide "numeric"-style big decimals[1] than provide big rationals[2], suggesting we're in good company. [1] https://en.wikipedia.org/wiki/List_of_arbitrary-precision_arithmetic_software#Languages [2] https://en.wikipedia.org/wiki/Rational_data_type#Language_support