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 EC4C6D1B198 for ; Sun, 4 Jul 2004 16:16:59 -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 97267-09 for ; Sun, 4 Jul 2004 19:16:57 +0000 (GMT) Received: from mail63.csoft.net (leary3.csoft.net [63.111.22.74]) by svr1.postgresql.org (Postfix) with SMTP id 50B62D1B182 for ; Sun, 4 Jul 2004 16:16:54 -0300 (ADT) Received: (qmail 4690 invoked by uid 1112); 4 Jul 2004 19:16:56 -0000 Date: Sun, 4 Jul 2004 14:16:56 -0500 (EST) From: Kris Jurka X-X-Sender: books@leary.csoft.net To: "Dario V. Fassi" Cc: pgsql-jdbc@postgresql.org, pgsql-bugs@postgresql.org, pgsql-sql@postgresql.org Subject: Re: [JDBC] Error in DatabaseMetaData.getColumns() with Views In-Reply-To: <40E6FD7F.50801@sistemat.com.ar> Message-ID: 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/46 X-Sequence-Number: 8628 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. It isn't clear that an operation like + should retain the same size restrictions as it's arguments. Consider adding two numeric(6,2) values of 9999.99, how do you handle the overflow? Your other arguments about the sizing of derived columns may make sense for your application, but it is unlikely that they make sense for all users. Note that you can put a cast into your view definition like so: CREATER VIEW v AS SELECT (a+b)::numeric(6,2) FROM tab; Kris Jurka