Horton

Thread

  1. simple division

    Martin Mueller <martinmueller@northwestern.edu> — 2018-12-04T20:29:38Z

    I have asked this question before and apologize for not remembering it.  How do you do simple division in postgres and get 10/4 with decimals?

This involves cast and numeric in odd ways that are not well explained in the documentation. For instance, you’d expect an example in the Mathematical Functions. But there isn’t.

The documentation of string functions is exemplary. The documentation of mathematical less so. Remember that it may be used by folks like me whose math is shaky. The MySQL documentation is better on this simple operation.


-----
Martin Mueller
Professor emeritus of English and Classics
Northwestern University

  2. Re: simple division

    Joshua D. Drake <jd@commandprompt.com> — 2018-12-04T20:38:07Z

    On 12/4/18 12:29 PM, Martin Mueller wrote:
>
> I have asked this question before and apologize for not remembering 
> it. How do you do simple division in postgres and get 10/4 with decimals?
>
> This involves cast and numeric in odd ways that are not well explained 
> in the documentation. For instance, you’d expect an example in the 
> Mathematical Functions. But there isn’t.
>
> The documentation of string functions is exemplary. The documentation 
> of mathematical less so. Remember that it may be used by folks like me 
> whose math is shaky. The MySQL documentation is better on this simple 
> operation.
>
I may be misunderstanding the question but:


select cast(x/y as numeric(10,4));

JD



> -----
>
> Martin Mueller
> Professor emeritus of English and Classics
>
> Northwestern University
>

-- 
Command Prompt, Inc. || http://the.postgres.company/ || @cmdpromptinc
***  A fault and talent of mine is to tell it exactly how it is.  ***
PostgreSQL centered full stack support, consulting and development.
Advocate: @amplifypostgres || Learn: https://postgresconf.org
*****     Unless otherwise stated, opinions are my own.   *****

  3. RE: simple division

    Igor Neyman <ineyman@perceptron.com> — 2018-12-04T20:38:15Z

    
From: Martin Mueller <martinmueller@northwestern.edu>
Sent: Tuesday, December 4, 2018 3:30 PM
To: pgsql-general <pgsql-general@postgresql.org>
Subject: simple division

I have asked this question before and apologize for not remembering it.  How do you do simple division in postgres and get 10/4 with decimals?

This involves cast and numeric in odd ways that are not well explained in the documentation. For instance, you’d expect an example in the Mathematical Functions. But there isn’t.

The documentation of string functions is exemplary. The documentation of mathematical less so. Remember that it may be used by folks like me whose math is shaky. The MySQL documentation is better on this simple operation.


-----
Martin Mueller
Professor emeritus of English and Classics
Northwestern University

There is nothing odd about:

select (12345678.1234/32.5678)::numeric(10,4);

Regards,
Igor Neyman

  4. Re: simple division

    Thomas Kellerer <spam_eater@gmx.net> — 2018-12-04T20:41:51Z

    Martin Mueller schrieb am 04.12.2018 um 21:29:
> I have asked this question before and apologize for not remembering
> it.  How do you do simple division in postgres and get 10/4 with
> decimals?

In the expression 10/4 both numbers are integers.
And an integer divsion does not yield decimals (that's the same as in every strongly typed programming language).

I am not entirely sure what the SQL standard says about such an expression, but e.g. SQL Server, SQLite, Firebird and DB2 behave the same as Postgres.
That is they apply integer division if all values are integers, and decimal division if at least one value is a decimal.

To get a division of decimals you need to specify at least one value as a decimal,

e.g. "select 10.0/4" or "select 10/4.0" whatever you prefer.

  5. Re: simple division

    David G. Johnston <david.g.johnston@gmail.com> — 2018-12-04T20:42:29Z

    On Tue, Dec 4, 2018 at 1:29 PM Martin Mueller
<martinmueller@northwestern.edu> wrote:
> I have asked this question before and apologize for not remembering it.  How do you do simple division in postgres and get 10/4 with decimals?
> This involves cast and numeric in odd ways that are not well explained in the documentation. For instance, you’d expect an example in the Mathematical Functions. But there isn’t.

select 10/4, 10.0/4, 10/4.0, 10.0/4.0;

The first one returns 2, the rest of them 2.5 - from which one can
infer that if both inputs are integer (type) the output is integer
(type) - if at least one input is non-integer (type) the output will
be as well.

If you want to cast...select 10/(4::numeric)...

David J.

  6. Re: simple division

    David G. Johnston <david.g.johnston@gmail.com> — 2018-12-04T20:45:02Z

    On Tue, Dec 4, 2018 at 1:38 PM Joshua D. Drake <jd@commandprompt.com> wrote:
> I may be misunderstanding the question but:
Indeed...
> select cast(x/y as numeric(10,4));

Your answer is 2.0 instead of the correct 2.5 - you need to cast
before the division, not after.

David J.

  7. Re: simple division

    Martin Mueller <martinmueller@northwestern.edu> — 2018-12-04T20:57:25Z

    I didn't formulate my question properly, because the query went like
 "select alldefects /wordcount" 
where alldefects and wordcount are integers.   But none of the different ways of putting the double colon seemed to work. 

The Postgres notation of this simple procedure is very unintuitive. I haven't been able to remember several times, and most people think of me as a person with a reasonably good memory. There is no obvious place in the documentation to look this up.


On 12/4/18, 2:45 PM, "David G. Johnston" <david.g.johnston@gmail.com> wrote:

    On Tue, Dec 4, 2018 at 1:38 PM Joshua D. Drake <jd@commandprompt.com> wrote:
    > I may be misunderstanding the question but:
    Indeed...
    > select cast(x/y as numeric(10,4));
    
    Your answer is 2.0 instead of the correct 2.5 - you need to cast
    before the division, not after.
    
    David J.

  8. Re: simple division

    David G. Johnston <david.g.johnston@gmail.com> — 2018-12-04T21:06:29Z

    On Tue, Dec 4, 2018 at 1:57 PM Martin Mueller
<martinmueller@northwestern.edu> wrote:
>
> I didn't formulate my question properly, because the query went like
>  "select alldefects /wordcount"
> where alldefects and wordcount are integers.   But none of the different ways of putting the double colon seemed to work.

IDK...the first thing that came to mind was to just stick it at the
end of the expression:

select x/y::numeric from (values (10,4)) vals (x,y)

And it worked...

If you want to propose a concrete documentation patch more power to
you but this doesn't come up enough to think that what we have is
materially deficient.  I'm sorry you are having trouble with it but
the lists do provide quick and customized answers for situations like
this.

David J.

  9. Re: simple division

    Ron <ronljohnsonjr@gmail.com> — 2018-12-04T21:08:30Z

    Use CAST() instead of ::.

SELECT CAST(alldefects AS NUMEREIC(10,4))/wordcount;

On 12/04/2018 02:57 PM, Martin Mueller wrote:
> I didn't formulate my question properly, because the query went like
>   "select alldefects /wordcount"
> where alldefects and wordcount are integers.   But none of the different ways of putting the double colon seemed to work.
>
> The Postgres notation of this simple procedure is very unintuitive. I haven't been able to remember several times, and most people think of me as a person with a reasonably good memory. There is no obvious place in the documentation to look this up.
>
>
> On 12/4/18, 2:45 PM, "David G. Johnston" <david.g.johnston@gmail.com> wrote:
>
>      On Tue, Dec 4, 2018 at 1:38 PM Joshua D. Drake <jd@commandprompt.com> wrote:
>      > I may be misunderstanding the question but:
>      Indeed...
>      > select cast(x/y as numeric(10,4));
>      
>      Your answer is 2.0 instead of the correct 2.5 - you need to cast
>      before the division, not after.
>      
>      David J.
>      
>

-- 
Angular momentum makes the world go 'round.

  10. Re: simple division

    Albrecht Dreß <albrecht.dress@arcor.de> — 2018-12-04T21:09:04Z

    Am 04.12.18 21:57 schrieb(en) Martin Mueller:
> I didn't formulate my question properly, because the query went like
>  "select alldefects /wordcount"
> where alldefects and wordcount are integers.

test=# create table xxx(alldefects bigint, wordcount bigint);
CREATE TABLE
test=# insert into xxx values (4, 10);
INSERT 0 1
test=# insert into xxx values (3, 17);
INSERT 0 1
test=# select alldefects::real / wordcount::real from xxx;
  ?column?
----------
       0.4
  0.176471
(2 rows)

Hth,
Albrecht.

  11. Re: simple division

    Martin Mueller <martinmueller@northwestern.edu> — 2018-12-04T21:36:35Z

    It worked, and I must have done something wrong. I'm probably not the only person who would find something like the following helpful:


division (integer division truncates the result)	10/3	3
division (with decimal results)	10/3::numeric	3.3333
division (rounded)	round(10/3::numeric, 2)	3.33

From an end user's the question "how do I divide two integers and limit the number of decimals" is surely a common one. And  if you look it up somewhere, division is probably the search word.  Now you could argue that the user should already know about formatting and rounding.  But some don't.

If you wanted to look up a rare wordform in a famous early 20th century dictionary of Old English, you had to know the root form of the word. If you already knew the root form, there is a good chance that you didn't need to look it up in the first place. If you didn't know the root form, the dictionary was no use. 

In this, single stop shopping for the three most common problems of simple division makes life easier for users.







On 12/4/18, 3:06 PM, "David G. Johnston" <david.g.johnston@gmail.com> wrote:

    On Tue, Dec 4, 2018 at 1:57 PM Martin Mueller
    <martinmueller@northwestern.edu> wrote:
    >
    > I didn't formulate my question properly, because the query went like
    >  "select alldefects /wordcount"
    > where alldefects and wordcount are integers.   But none of the different ways of putting the double colon seemed to work.
    
    IDK...the first thing that came to mind was to just stick it at the
    end of the expression:
    
    select x/y::numeric from (values (10,4)) vals (x,y)
    
    And it worked...
    
    If you want to propose a concrete documentation patch more power to
    you but this doesn't come up enough to think that what we have is
    materially deficient.  I'm sorry you are having trouble with it but
    the lists do provide quick and customized answers for situations like
    this.
    
    David J.

  12. Re: simple division

    Thomas Kellerer <spam_eater@gmx.net> — 2018-12-04T21:38:48Z

    Martin Mueller schrieb am 04.12.2018 um 21:57:
> I didn't formulate my question properly, because the query went like
>   "select alldefects /wordcount"
> where alldefects and wordcount are integers.   
> But none of the different ways of putting the double colon seemed to
> work.
One way is to make one of the integers a decimal by multiplying with 1.0

    select alldefects * 1.0 / wordcount

> The Postgres notation of this simple procedure is very unintuitive. I
> haven't been able to remember several times, and most people think of
> me as a person with a reasonably good memory.

Postgres supports the SQL standard's CAST operator:

    select cast(alldefects as decimal) / wordcount

The "Postgres way" would be:

    select alldefects::decimal / wordcount

> There is no obvious place in the documentation to look this up.

This is covered in the chapter "Type Casts"

https://www.postgresql.org/docs/current/sql-expressions.html#SQL-SYNTAX-TYPE-CASTS

  13. Re: simple division

    Rob Sargent <robjsargent@gmail.com> — 2018-12-04T21:51:31Z

    On 12/4/18 2:36 PM, Martin Mueller wrote:
> It worked, and I must have done something wrong. I'm probably not the only person who would find something like the following helpful:
>
>
> division (integer division truncates the result)	10/3	3

The math types might take offense here, with the use of "truncates".  
Integer division really ask how many times can one subtract the 
numerator from the denominator without going negative (or how many times 
does the numerator "go into" the denominator).

It may seem a nuisance, but int division is a useful construct and must 
be supported (and be the default). (If you have 10 people to transport 
in cars which hold four (all can drive) 10/4 = 3 ;) )

  14. Re: simple division

    Gavin Flower <gavinflower@archidevsys.co.nz> — 2018-12-05T04:33:28Z

    On 05/12/2018 10:51, Rob Sargent wrote:
>
> On 12/4/18 2:36 PM, Martin Mueller wrote:
>> It worked, and I must have done something wrong. I'm probably not the 
>> only person who would find something like the following helpful:
>>
>>
>> division (integer division truncates the result)    10/3    3
>
> The math types might take offense here, with the use of "truncates".  
> Integer division really ask how many times can one subtract the 
> numerator from the denominator without going negative (or how many 
> times does the numerator "go into" the denominator).
>
> It may seem a nuisance, but int division is a useful construct and 
> must be supported (and be the default). (If you have 10 people to 
> transport in cars which hold four (all can drive) 10/4 = 3 ;) )
>
>
>
>
Hmm...

10 / 4 = 2

  15. Re: simple division

    Rob Sargent <robjsargent@gmail.com> — 2018-12-05T07:07:21Z

    
> On Dec 4, 2018, at 9:33 PM, Gavin Flower <GavinFlower@archidevsys.co.nz> wrote:
> 
>> On 05/12/2018 10:51, Rob Sargent wrote:
>> 
>>> On 12/4/18 2:36 PM, Martin Mueller wrote:
>>> It worked, and I must have done something wrong. I'm probably not the only person who would find something like the following helpful:
>>> 
>>> 
>>> division (integer division truncates the result)    10/3    3
>> 
>> The math types might take offense here, with the use of "truncates".  Integer division really ask how many times can one subtract the numerator from the denominator without going negative (or how many times does the numerator "go into" the denominator).
>> 
>> It may seem a nuisance, but int division is a useful construct and must be supported (and be the default). (If you have 10 people to transport in cars which hold four (all can drive) 10/4 = 3 ;) )
>> 
>> 
>> 
>> 
> Hmm...
> 
> 10 / 4 = 2
> 
And two are left stranded!
 The point is that integer math has its place. You cant have 2.5 cars. So 10/4 in this context is 3. 
More correctly the calculation is 
10/4 + 10%4>0 ? 1 :0 = 3

(Maybe psql does have % so mod(10,4))

  16. Re: simple division

    Gavin Flower <gavinflower@archidevsys.co.nz> — 2018-12-05T09:13:10Z

    On 05/12/2018 20:07, Rob Sargent wrote:
>
>> On Dec 4, 2018, at 9:33 PM, Gavin Flower <GavinFlower@archidevsys.co.nz> wrote:
>>
>>> On 05/12/2018 10:51, Rob Sargent wrote:
>>>
>>>> On 12/4/18 2:36 PM, Martin Mueller wrote:
>>>> It worked, and I must have done something wrong. I'm probably not the only person who would find something like the following helpful:
>>>>
>>>>
>>>> division (integer division truncates the result)    10/3    3
>>> The math types might take offense here, with the use of "truncates".  Integer division really ask how many times can one subtract the numerator from the denominator without going negative (or how many times does the numerator "go into" the denominator).
>>>
>>> It may seem a nuisance, but int division is a useful construct and must be supported (and be the default). (If you have 10 people to transport in cars which hold four (all can drive) 10/4 = 3 ;) )
>>>
>>>
>>>
>>>
>> Hmm...
>>
>> 10 / 4 = 2
>>
> And two are left stranded!
>   The point is that integer math has its place. You cant have 2.5 cars. So 10/4 in this context is 3.
> More correctly the calculation is
> 10/4 + 10%4>0 ? 1 :0 = 3
>
> (Maybe psql does have % so mod(10,4))
>
>
SELECT ceil(10/4.0);

Is what you want for that example.

  17. Re: simple division

    Geoff Winkless <pgsqladmin@geoff.dj> — 2018-12-05T11:05:49Z

    On Wed, 5 Dec 2018 at 09:13, Gavin Flower <GavinFlower@archidevsys.co.nz> wrote:
> SELECT ceil(10/4.0);
>
> Is what you want for that example.

Except that implies that "number of people who can fit in a car" is a
real number, not a whole.

IMO it's fundamentally broken that SQL doesn't cast the result of a
divide into a numeric value - the potential for unexpected errors
creeping into calculations is huge; however that's the standard and
no-one's going to change it now.

Having said that it's worth noting that those in the Other Place think
that it's broken enough to go against the standard (they have a DIV b
for integer divide and a/b for float).

Geoff

  18. Re: simple division

    Gavin Flower <gavinflower@archidevsys.co.nz> — 2018-12-05T12:45:10Z

    On 06/12/2018 00:05, Geoff Winkless wrote:
> On Wed, 5 Dec 2018 at 09:13, Gavin Flower <GavinFlower@archidevsys.co.nz> wrote:
>> SELECT ceil(10/4.0);
>>
>> Is what you want for that example.
> Except that implies that "number of people who can fit in a car" is a
> real number, not a whole.
>
> IMO it's fundamentally broken that SQL doesn't cast the result of a
> divide into a numeric value - the potential for unexpected errors
> creeping into calculations is huge; however that's the standard and
> no-one's going to change it now.
>
> Having said that it's worth noting that those in the Other Place think
> that it's broken enough to go against the standard (they have a DIV b
> for integer divide and a/b for float).
>
> Geoff
>
If you divide one integer by another, then it is logical to get an 
integer as as the answer.

  19. Re: simple division

    Geoff Winkless <pgsqladmin@geoff.dj> — 2018-12-05T12:54:41Z

    On Wed, 5 Dec 2018 at 12:45, Gavin Flower <GavinFlower@archidevsys.co.nz> wrote:
> If you divide one integer by another, then it is logical to get an
> integer as as the answer.

Hmm. It might fit with what a computer scientist might expect (or
rather, not be surprised about), but I don't think you can say that
it's "logical".

Where's the logical progression in step 3 here:

1 You asked the computer a question

2 The values you passed to it don't have decimal points

...

4 Ergo, you wanted an answer that was incorrect.

Geoff

  20. Re: simple division

    Adrian Klaver <adrian.klaver@aklaver.com> — 2018-12-05T13:32:14Z

    On 12/5/18 4:45 AM, Gavin Flower wrote:
> On 06/12/2018 00:05, Geoff Winkless wrote:
>> On Wed, 5 Dec 2018 at 09:13, Gavin Flower 
>> <GavinFlower@archidevsys.co.nz> wrote:
>>> SELECT ceil(10/4.0);

>> Geoff
>>
> If you divide one integer by another, then it is logical to get an 
> integer as as the answer.

Hmm, grab any of my calculators and divide 10/4 and get 2.5. Seems not 
everybody agrees with that logic:)


-- 
Adrian Klaver
adrian.klaver@aklaver.com

  21. Re: simple division

    Raymond Brinzer <ray.brinzer@gmail.com> — 2018-12-05T13:32:55Z

    On Wed, Dec 5, 2018 at 7:55 AM Geoff Winkless <pgsqladmin@geoff.dj> wrote:

> Where's the logical progression in step 3 here:
>
> 1 You asked the computer a question
>
> 2 The values you passed to it don't have decimal points
>
> ...
>
> 4 Ergo, you wanted an answer that was incorrect.
>

Well put.  However the nature of the question you asked does not
necessarily allow for a correct finite answer.  If I ask for 10/3, for
instance, or 1/0.  To play devil's advocate, then:  you should have known
that some of the answers would need to be truncated.  This just truncates a
little more aggressively.  ;-)

-- 
Ray Brinzer

  22. Re: simple division

    Tom Lane <tgl@sss.pgh.pa.us> — 2018-12-05T15:22:49Z

    Geoff Winkless <pgsqladmin@geoff.dj> writes:
> IMO it's fundamentally broken that SQL doesn't cast the result of a
> divide into a numeric value - the potential for unexpected errors
> creeping into calculations is huge; however that's the standard and
> no-one's going to change it now.
> Having said that it's worth noting that those in the Other Place think
> that it's broken enough to go against the standard (they have a DIV b
> for integer divide and a/b for float).

Well, this isn't really blame-able on the SQL standard; it's a
Postgres-ism.  What the spec says (in SQL99, 6.26 <numeric value
expression>) is

         1) If the declared type of both operands of a dyadic arithmetic
            operator is exact numeric, then the declared type of the
            result is exact numeric, with precision and scale determined
            as follows:

            a) Let S1 and S2 be the scale of the first and second operands
              respectively.

            b) The precision of the result of addition and subtraction is
              implementation-defined, and the scale is the maximum of S1
              and S2.

            c) The precision of the result of multiplication is
              implementation-defined, and the scale is S1 + S2.

            d) The precision and scale of the result of division is
              implementation-defined.

         2) If the declared type of either operand of a dyadic arithmetic
            operator is approximate numeric, then the declared type of the
            result is approximate numeric. The precision of the result is
            implementation-defined.

Postgres' integer types map onto the standard as exact numerics with
scale 0.  (The precision aspect is a bit squishy, since their maximum
values aren't powers of 10, but let's disregard that.)  Postgres'
integer division operator meets the spec with the stipulation that
the "implementation-defined" scale of the result is 0.  Other SQL
implementations can and do define that differently --- if they even
have an "integer" data type, which some do not.

Anyway, the bottom line here is that we're balancing surprise factor
for novices against twenty-plus years of backwards compatibility,
and the latter is going to win.

			regards, tom lane

  23. Re: simple division

    Martin Mueller <martinmueller@northwestern.edu> — 2018-12-05T15:53:08Z

    I take the point that two decades of backward compatibility should and will win. That said,  it's an easy enough thing to right the balance for novices and put in a really obvious place in the documentation what you should do if you want to divide two integers and get the results with the number of decimals of your choice. I made one suggestion how this could be done. A better way might be a short paragraph like

A note on division:  if you divide two constants or variables defined as integers, the default will be an integer. If you want the result with decimals, add "::numeric".  If you want to limit the decimals, use the round() function:
	Select 10/3:		3
	Select 10/3::numeric	3.33333
	Round(select 10/3::numeric, 3)		3.333
For more detail see the sections on ...





`
On 12/5/18, 9:23 AM, "Tom Lane" <tgl@sss.pgh.pa.us> wrote:

    Geoff Winkless <pgsqladmin@geoff.dj> writes:
    > IMO it's fundamentally broken that SQL doesn't cast the result of a
    > divide into a numeric value - the potential for unexpected errors
    > creeping into calculations is huge; however that's the standard and
    > no-one's going to change it now.
    > Having said that it's worth noting that those in the Other Place think
    > that it's broken enough to go against the standard (they have a DIV b
    > for integer divide and a/b for float).
    
    Well, this isn't really blame-able on the SQL standard; it's a
    Postgres-ism.  What the spec says (in SQL99, 6.26 <numeric value
    expression>) is
    
             1) If the declared type of both operands of a dyadic arithmetic
                operator is exact numeric, then the declared type of the
                result is exact numeric, with precision and scale determined
                as follows:
    
                a) Let S1 and S2 be the scale of the first and second operands
                  respectively.
    
                b) The precision of the result of addition and subtraction is
                  implementation-defined, and the scale is the maximum of S1
                  and S2.
    
                c) The precision of the result of multiplication is
                  implementation-defined, and the scale is S1 + S2.
    
                d) The precision and scale of the result of division is
                  implementation-defined.
    
             2) If the declared type of either operand of a dyadic arithmetic
                operator is approximate numeric, then the declared type of the
                result is approximate numeric. The precision of the result is
                implementation-defined.
    
    Postgres' integer types map onto the standard as exact numerics with
    scale 0.  (The precision aspect is a bit squishy, since their maximum
    values aren't powers of 10, but let's disregard that.)  Postgres'
    integer division operator meets the spec with the stipulation that
    the "implementation-defined" scale of the result is 0.  Other SQL
    implementations can and do define that differently --- if they even
    have an "integer" data type, which some do not.
    
    Anyway, the bottom line here is that we're balancing surprise factor
    for novices against twenty-plus years of backwards compatibility,
    and the latter is going to win.
    
    			regards, tom lane

  24. Re: simple division

    Gavin Flower <gavinflower@archidevsys.co.nz> — 2018-12-05T17:31:29Z

    On 06/12/2018 02:32, Adrian Klaver wrote:
> On 12/5/18 4:45 AM, Gavin Flower wrote:
>> On 06/12/2018 00:05, Geoff Winkless wrote:
>>> On Wed, 5 Dec 2018 at 09:13, Gavin Flower 
>>> <GavinFlower@archidevsys.co.nz> wrote:
>>>> SELECT ceil(10/4.0);
>
>>> Geoff
>>>
>> If you divide one integer by another, then it is logical to get an 
>> integer as as the answer.
>
> Hmm, grab any of my calculators and divide 10/4 and get 2.5. Seems not 
> everybody agrees with that logic:)
>
>
Calculators normally work in floating point (in fact, as far as I am 
aware, they never work in integer mode by default) , unless you are 
either doing symbolic maths or numbers that are integer based like 
hexadecimal.

So your example does not contrdict what I said.

  25. Re: simple division

    Alvaro Herrera <alvherre@2ndquadrant.com> — 2018-12-05T20:37:27Z

    On 2018-Dec-06, Gavin Flower wrote:

> Calculators normally work in floating point (in fact, as far as I am aware,
> they never work in integer mode by default),

The reason they don't work in "integer mode" is because it doesn't make
sense.

We only have this thing called "integer division" because it's a cheap
thing to implement in terms of machine instructions.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services