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.
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
