X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 4652B5E46C2 for ; Tue, 31 Aug 2004 12:13:46 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 47556-08 for ; Tue, 31 Aug 2004 15:13:47 +0000 (GMT) Received: from smtp103.mail.sc5.yahoo.com (smtp103.mail.sc5.yahoo.com [66.163.169.222]) by svr1.postgresql.org (Postfix) with SMTP id 2A29A5E46F4 for ; Tue, 31 Aug 2004 12:13:39 -0300 (ADT) Received: from unknown (HELO jupiter.black-lion.info) (janwieck@68.80.245.191 with login) by smtp103.mail.sc5.yahoo.com with SMTP; 31 Aug 2004 15:13:44 -0000 Received: from [172.21.8.18] (ismtp.afilias.com [216.217.55.254]) (authenticated bits=0) by jupiter.black-lion.info (8.12.10/8.12.9) with ESMTP id i7VFDhT7072037; Tue, 31 Aug 2004 11:13:43 -0400 (EDT) (envelope-from JanWieck@Yahoo.com) Message-ID: <41349568.6020400@Yahoo.com> Date: Tue, 31 Aug 2004 11:12:40 -0400 From: Jan Wieck User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Lane Cc: Rajesh Kumar Mallah , Michael Glaesemann , pgsql-sql@postgresql.org Subject: Re: Arbitrary precision arithmatic with pgsql References: <41346727.8080901@trade-india.com> <1089006C-FB4B-11D8-A2A0-000A95C88220@myrealbox.com> <41347A0F.70300@trade-india.com> <41348898.1070107@Yahoo.com> <29456.1093964692@sss.pgh.pa.us> In-Reply-To: <29456.1093964692@sss.pgh.pa.us> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=1.6 tagged_above=0.0 required=5.0 tests=RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL X-Spam-Level: * X-Archive-Number: 200408/346 X-Sequence-Number: 18843 On 8/31/2004 11:04 AM, Tom Lane wrote: > Jan Wieck writes: >> I agree that doing >> select 2::numeric ^ 100; >> should emit some sort of a warning. > > I do not. The conversion of 2::numeric to float is exact, so AFAICS > the only way to do that would be to make *every* coercion of numeric to > float emit a warning. This is not a reasonable response to the fact > that Rajesh is unaware of the set of available operators. Moreover > it would essentially break float constants (since "2.0" starts life > as numeric and is only cast to float when the context demands). I thought they start life as an unknown literal ... that of course changes things. Jan > > I'd be in favor of adding a numeric^numeric operator to ease access to > the existing pow() code, but I'm not sure this makes the issue go away > entirely. It looks like "select 2 ^ 100" would still default to being > a float operation. > > regression=# create operator ^ (procedure=pow, leftarg=numeric, rightarg=numeric); > CREATE OPERATOR > regression=# select 2::numeric ^ 100; > ?column? > -------------------------------------------------- > 1267650600228229401496703205376.0000000000000000 > (1 row) > > regression=# select 2 ^ 100; > ?column? > ---------------------- > 1.26765060022823e+30 > (1 row) > > regression=# select 2.0 ^ 100; > ?column? > -------------------------------------------------- > 1267650600228229401496703205376.0000000000000000 > (1 row) > > > regards, tom lane -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #