Paul,
> Thanks for the reply. Much of what you say is as we expected.
> I see that 7.3 has addressed the "Unable to identify an operator
> '=' for types 'numeric' and 'double precision'" problem, but
> I'm not sure how. Context-sensitive approach? Overloaded operator
> approach? Something e
Josh,
Thanks for the reply. Much of what you say is as we expected.
I see that 7.3 has addressed the "Unable to identify an operator
'=' for types 'numeric' and 'double precision'" problem, but
I'm not sure how. Context-sensitive approach? Overloaded operator
approach? Something else ( is the
"Josh Berkus" <[EMAIL PROTECTED]> writes:
> Now, that's interesting. Why would defining a "numeric = float" have
> broken "numeric = integer"? There's no reason I can think of.
The problem probably is that the parser now finds two possible
interpretations that look equally good to it, so it ca
Paul Ogden <[EMAIL PROTECTED]> writes:
> select count(wuid) from WU where wuActive = 0.0 --throws the
> following exception:
> "Unable to identify an operator '=' for types 'numeric' and 'double
> precision' You will have to retype this query using an explicit cast"
This is fixed as of 7.3. (
Paul,
> "Unable to identify an operator '=' for types 'numeric' and 'double
> precision' You will have to retype this query using an explicit cast"
This is due, as you surmised, to decimal values defaulting to floats.
While there is little problem with an = operator for numeric and
float, you wo
Hello,
Our application development group has observed what we
feel is inconsistent behavior when comparing numeric
column references to constant/literal values in SQL.
I would appreciate comments on the best approach to
this problem that will allow for the highest
portability of our applicati
