X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [64.117.224.193]) by svr1.postgresql.org (Postfix) with ESMTP id 28C2130EFF8 for ; Tue, 17 Jun 2003 07:06:03 +0000 (GMT) Received: from svr1.postgresql.org ([64.117.224.193]) by localhost (svr1.postgresql.org [64.117.224.193]) (amavisd-new, port 10024) with ESMTP id 44338-07 for ; Tue, 17 Jun 2003 04:05:52 -0300 (ADT) Received: from www.pspl.co.in (www.pspl.co.in [202.54.11.65]) by svr1.postgresql.org (Postfix) with ESMTP id C728830EED5 for ; Tue, 17 Jun 2003 04:05:49 -0300 (ADT) Received: (from root@localhost) by www.pspl.co.in (8.11.6/8.11.6) id h5H75mc01995 for ; Tue, 17 Jun 2003 12:35:48 +0530 Received: from daithan (daithan.intranet.pspl.co.in [192.168.7.161]) by www.pspl.co.in (8.11.6/8.11.0) with ESMTP id h5H75l901985; Tue, 17 Jun 2003 12:35:48 +0530 From: "Shridhar Daithankar" To: pgsql-hackers@postgresql.org, pgsql-sql@postgresql.org Date: Tue, 17 Jun 2003 12:35:00 +0530 MIME-Version: 1.0 Subject: Re: [HACKERS] Our FLOAT(p) precision does not conform to spec Reply-To: shridhar_daithankar@persistent.co.in Message-ID: <3EEF0AF4.16718.1AEA03@localhost> In-reply-to: <7114.1055801746@sss.pgh.pa.us> X-mailer: Pegasus Mail for Windows (v4.02) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body X-Archive-Number: 200306/219 X-Sequence-Number: 13977 On 16 Jun 2003 at 18:15, Tom Lane wrote: > This is a straightforward change and would not break pg_dump files, > since fortunately pg_dump always references the underlying types and > never refers to anything as FLOAT(p). But I wonder whether it is > likely to break many existing applications. There is a hazard of some > existing app asking for (what it thinks is) float8 and getting float4 > instead. Especially apps. which rely on number(3) not to accept anything greate than +/- 999. I hate the syntax of putting decimal digits as range checkers in SQL field. But oracle does that and consequently lot of oracle apps rely on it. I won't be surprised if float(p) notion brings same assurance to such app developers. I think this would become and FAQ after changes are implemented. Who reads release notes anyway?..:-) > Is it worth trying to provide some sort of backwards-compatibility mode? > We could imagine adding a GUC variable to select binary or decimal > precision, but I really don't want to. It would increase the amount of > work needed by more than an order of magnitude, and this problem doesn't > seem worth it. I'd rather just list this under Incompatibilities in the > 7.4 release notes. Is it possible to have float-2(p) and float-10(p)? Would it be adding code sections instead of replacing it? That would be cleaner than GUC variable. Everything defaults to float-10(p) for backward compatibility for a period of a release and in 7.5, it gets switched to float-2(p). In the meantime, the behaviour remains available who cares to read the docs and notes. Just a thought.. Bye Shridhar -- Genderplex, n.: The predicament of a person in a restaurant who is unable to determine his or her designated restroom (e.g., turtles and tortoises). -- Rich Hall, "Sniglets"