Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Is this an open item?
>
> Yes. (Fooling with it right now, in fact, in a desultory way ...)
OK, added.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Is this an open item?
Yes. (Fooling with it right now, in fact, in a desultory way ...)
regards, tom lane
---(end of broadcast)---
TIP 6: Have you searched our list archives?
ht
Is this an open item?
---
Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > One problem is, that division already has an inherently inexact
> > result. Do you intend to rip that out too while at it? (Just
> > kidd
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Seems we need to resolve this before beta2.
>
> Not really. It's just a bug; we have others.
Oh, it doesn't effect initdb?
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] |
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Seems we need to resolve this before beta2.
Not really. It's just a bug; we have others.
regards, tom lane
---(end of broadcast)---
TIP 6: Have you searched our list archives?
h
Bruce Momjian wrote:
>
> Seems we need to resolve this before beta2.
I'd go with making the NUMERIC default precision 16 for v7.3, so
we are backwards compatible on this release (except that it is
now a predictable 16 digit precision instead of an hardware
implementation dependent one).
For v7.
Seems we need to resolve this before beta2.
---
Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > One problem is, that division already has an inherently inexact
> > result. Do you intend to rip that out too while
Jan Wieck <[EMAIL PROTECTED]> writes:
> One problem is, that division already has an inherently inexact
> result. Do you intend to rip that out too while at it? (Just
> kidding)
No, but that too is now delivering less precision than it used to:
regression=# select 10.1/7.0;
?column?
-
Tom Lane wrote:
>
> I have noticed a change in behavior following the recent changes for
> casting of numeric constants. In prior releases, we got
>
> regression=# select log(10.1);
>log
> --
> 1.00432137378264
> (1 row)
>
> CVS tip gives
>
> regression=# select log(1
When you say:
> So proposal #1 is to rip out the numeric versions of these functions.
you mean remove the ability to do transendentals on numerics to prevent
such unusual auto-casting? Are you suggesting that in all other cases,
autocast to numeric is OK? I am a little confused.
I have noticed a change in behavior following the recent changes for
casting of numeric constants. In prior releases, we got
regression=# select log(10.1);
log
--
1.00432137378264
(1 row)
CVS tip gives
regression=# select log(10.1);
log
--
1.0043213738
11 matches
Mail list logo