"Josh Berkus" <[EMAIL PROTECTED]> writes:
> And, just to throw a banana peel onto the sidewalk of argument, there is
> even a reason to keep things the way they are. [ ... ]
> Thus there's a good reason for the database to be indecisive about
> float/numeric decisions, and good reason for you to
Craig Longman <[EMAIL PROTECTED]> writes:
> so, i presume then that this is a problem in the database because no-one
> has sat down and made sure that all the possible combinations of
> built-in datatypes are handled for all the various built-in
> functions/operators?
No, that's not it, and that
On 17 Jun 2001 21:02:03 -0500, Ross J. Reedstrom wrote:
> On Sat, Jun 16, 2001 at 01:07:29AM -0400, Craig Longman wrote:
>
> numeric casts>
>
> Tom Lane has already addressed the 'why is it this way' question. I'll
> address your proposed work arounds.
he did. i tried looking in pg-hackers for
On Sat, Jun 16, 2001 at 01:07:29AM -0400, Craig Longman wrote:
numeric casts>
Tom Lane has already addressed the 'why is it this way' question. I'll
address your proposed work arounds.
>
> the only solution i can think of, if it is possible, is to have a script
> that the client would need to
Craig Longman <[EMAIL PROTECTED]> writes:
> select (unitcost*probability) from oppproducttype
> ERROR: Unable to identify an operator '*' for types 'numeric' and
> 'float8'
> You will have to retype this query using an explicit cast
> is this kind of thing a regular thing for postgresql?
