Re: integer instead of 'double precision'? - Mailing list pgsql-general

From Chris Angelico
Subject Re: integer instead of 'double precision'?
Date
Msg-id CAPTjJmqwtea9kz1VrFOttBkr-jKHnC90Mnzt9rDSTtxrdQB5Og@mail.gmail.com
Whole thread Raw
In response to Re: integer instead of 'double precision'?  (Willy-Bas Loos <willybas@gmail.com>)
List pgsql-general
On Tue, Nov 13, 2012 at 12:16 AM, Willy-Bas Loos <willybas@gmail.com> wrote:
> On Fri, Sep 9, 2011 at 5:09 PM, Guillaume Lelarge <guillaume@lelarge.info>
> wrote:
>>
>> You divide an integer with an integer, that should give you an integer.
>
> Can you tell me the reasoning behind that idea?
> Is it a rule that the output type of an operator must equal the input type?
> In this case that doesn't seem locigal. I think that the "/" operator should
> return something that allows fractions, since the operator creates fractions
> so frequently.

This is an argument that comes up regularly on the Python list, partly
because version 2 had int/int -> int, but version 3 declared that
int/int -> float made more sense.

One of the problems of going to floating point is that it's not a
superset of integers - especially not when your integer type supports
arbitrary precision. It might seem obvious that 7/2 should yield 3.5
and not 3, but what about when the numbers are so large that you lose
precision by going float? Or are there to be some cases where int/int
makes float and some where it makes int? That would be nicely
confusing.

I'm generally happy with either behaviour, as long as its consistent,
and as long as it can be overridden with an explicit type cast when
the other is needed.

ChrisA


pgsql-general by date:

Previous
From: Willy-Bas Loos
Date:
Subject: Re: integer instead of 'double precision'?
Next
From: Tom Lane
Date:
Subject: Re: Can dml realize the partition table's rule and make good execution plan?