From: Kris Jurka <books@ejurka.com>
To: Dario V. Fassi <software@sistemat.com.ar>
Cc: pgsql-jdbc@postgresql.org
Cc: pgsql-bugs@postgresql.org
Cc: pgsql-sql@postgresql.org
Subject: Re: [JDBC] Error in DatabaseMetaData.getColumns() with Views
Date: Sun, 4 Jul 2004 14:16:56 -0500 (EST)
Message-ID: <Pine.BSO.4.56.0407041330180.26773@leary.csoft.net> (raw)
In-Reply-To: <40E6FD7F.50801@sistemat.com.ar>
References: <40E6088E.6030703@yahoo.com.ar>
<Pine.BSO.4.56.0407030343090.19721@leary.csoft.net>
<40E6E7AF.5020306@sistemat.com.ar>
<40E6FD7F.50801@sistemat.com.ar>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-sql@postgresql.org
Cc: books@ejurka.com, software@sistemat.com.ar, pgsql-jdbc@postgresql.org, pgsql-bugs@postgresql.org
Subject: Re: [JDBC] Error in DatabaseMetaData.getColumns() with Views
In-Reply-To: <Pine.BSO.4.56.0407041330180.26773@leary.csoft.net>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox