X-Original-To: pgsql-bugs-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 39C7CD1B1B0; Sun, 4 Jul 2004 19:51:26 -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 59089-04; Sun, 4 Jul 2004 22:51:24 +0000 (GMT) Received: from megazone.bigpanda.com (megazone.bigpanda.com [64.147.171.210]) by svr1.postgresql.org (Postfix) with ESMTP id 6FC8ED1B182; Sun, 4 Jul 2004 19:51:20 -0300 (ADT) Received: by megazone.bigpanda.com (Postfix, from userid 1001) id 35FE435853; Sun, 4 Jul 2004 15:51:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by megazone.bigpanda.com (Postfix) with ESMTP id 3124135852; Sun, 4 Jul 2004 15:51:21 -0700 (PDT) Date: Sun, 4 Jul 2004 15:51:21 -0700 (PDT) From: Stephan Szabo To: Kris Jurka Cc: "Dario V. Fassi" , pgsql-jdbc@postgresql.org, pgsql-bugs@postgresql.org, pgsql-sql@postgresql.org Subject: Re: [JDBC] Error in DatabaseMetaData.getColumns() with Views In-Reply-To: Message-ID: <20040704153840.Y52747@megazone.bigpanda.com> References: <40E6088E.6030703@yahoo.com.ar> <40E6E7AF.5020306@sistemat.com.ar> <40E6FD7F.50801@sistemat.com.ar> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.0 tagged_above=0.0 required=5.0 tests= X-Spam-Level: X-Archive-Number: 200407/47 X-Sequence-Number: 8629 On Sun, 4 Jul 2004, Kris Jurka wrote: > On Sat, 3 Jul 2004, Dario V. Fassi wrote: > > > In the sample adjunct, you can see that error arise at the time when the > > view's sql text is parsed and saved in database catalog. > > Then generic NUMERIC type is forced for every calculated column without > > regard or precision. > > And at execute time the f2 column has varying type decimals (in row 2 > > you can see 4 decimals and in other rows has 3 decimals), this is not a > > behavior , this is an ERROR. [Jumping in, because this was the first message of the thread I've seen] Technically, the correct behavior by spec would be an implementation-defined precision and a particular scale based on the argument scales. So, having numeric(6,2)+numeric(6,2) return numeric(65535, 2) is fine. Returning numeric(65535, 65531) isn't technically, but I don't think this is an issue in the jdbc metadata getting as much as an issue in the database proper.