Received: from localhost (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id 9DE63475DA3 for ; Tue, 12 Nov 2002 14:11:47 -0500 (EST) Received: from davinci.ethosmedia.com (davinci.ethosmedia.com [209.10.40.250]) by postgresql.org (Postfix) with ESMTP id 0CAEF475AEC for ; Tue, 12 Nov 2002 14:11:47 -0500 (EST) Received: from [66.219.92.2] (HELO chocolate-mousse) by davinci.ethosmedia.com (CommuniGate Pro SMTP 3.5.9) with ESMTP id 1822833; Tue, 12 Nov 2002 11:15:08 -0800 Content-Type: text/plain; charset="iso-8859-1" From: Josh Berkus Reply-To: josh@agliodbs.com Organization: Aglio Database Solutions To: pogden@claresco.com, pgsql-sql@postgresql.org Subject: Re: Inconsistent or incomplete behavior obverse in where Date: Tue, 12 Nov 2002 11:13:09 -0800 X-Mailer: KMail [version 1.4] References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200211121113.09365.josh@agliodbs.com> X-Virus-Scanned: by AMaViS new-20020517 X-Archive-Number: 200211/198 X-Sequence-Number: 10340 Paul, > Thanks for the reply. Much of what you say is as we expected.=20=20 > I see that 7.3 has addressed the "Unable to identify an operator=20 > '=3D' for types 'numeric' and 'double precision'" problem, but=20 > I'm not sure how. Context-sensitive approach? Overloaded operator > approach? Something else ( is there )? A modification of the operators available. > If the release of 7.3 is soon, perhaps we can get by with the=20 > band-aid approach of overloading the comparison operators=20 > until such time as the new version is available. Production > for us is next spring, so maybe we'll be okay on this one. > This approach would certainly allow our development team to > right their code one way. 7.3 final is expected before December. --=20 -Josh Berkus