kris,
Next you can see how the same test-case is handled by DB2.
-- IBM DB2 V6.1 for Linux
CREATE TABLE userid.t (
f1 numeric(6,3),
f2 numeric(6,4),
f3 numeric(8,2)
);
create view userid.v as
select
(f1+f2+f3) as fsum,
coalesce(f1,f2,f3) as fcoal,
(f1*f2*f3) as fprod,
(f1/f2) as fdiv
I have found that the problem is worst.
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 colu
Stephan Szabo wrote:
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 fo
Stephan, look at the samples I send in previous posts , from PgSql and
Db2.
I know it's a no ease task to change all that behavior , but you must
agree that a Numeric column with the fractional part varing from row to
row are different data types and break relational rules.
If this is the case
On Sun, 4 Jul 2004, Dario V. Fassi wrote:
> Stephan, look at the samples I send in previous posts , from PgSql and Db2.
I don't see any samples apart from the original view descriptions and the
getColumns results. I see some implication about db2 but no details. My
guess is that the messages a
On Sun, 4 Jul 2004, Dario V. Fassi wrote:
>
>
> Stephan Szabo wrote:
>
> >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
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
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
