Skip site navigation (1) Skip section navigation (2)

Re: BUG #2357: docs for mod() are wrong

From: Philip Crotwell <crotwell(at)seis(dot)sc(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #2357: docs for mod() are wrong
Date: 2006-03-25 01:07:23
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
On Mar 24, 2006, at 4:39 PM, Tom Lane wrote:

> "Philip Crotwell" <crotwell(at)seis(dot)sc(dot)edu> writes:
>> It would be nice if mod could directly take a double,
> Given the inherent approximate nature of float arithmetic, I'm not sure
> this makes a lot of sense.  How often do you really do modulo on 
> floats?

We have a table with double longitudes as a column, but it is always a 
problem as to whether the earth is -180 to 180 or 0 to 360. To get 
around it we so something like
SELECT * FROM table WHERE minlon < mod(lon, 360) AND maxlon > mod(lon, 
The basic idea is that using mod(lon, 360) allows us to find entries 
with lon=-90 or lon=270 as they are really the same spot on the ground.

It isn't that big of a deal as you can work around it by casting, but 
the fact mod works with a numeric but not with a double just seemed 
strange to me.


>> but if not the docs
>> should say that the arguments should be NUMERIC
> That would be incorrect.  We have it for all the exact numeric types.
> regression=# \df mod
>                      List of functions
>    Schema   | Name | Result data type | Argument data types
> ------------+------+------------------+---------------------
>  pg_catalog | mod  | bigint           | bigint, bigint
>  pg_catalog | mod  | integer          | integer, integer
>  pg_catalog | mod  | integer          | integer, smallint
>  pg_catalog | mod  | integer          | smallint, integer
>  pg_catalog | mod  | numeric          | numeric, numeric
>  pg_catalog | mod  | smallint         | smallint, smallint
> (6 rows)
> I don't see an easy way to cram that statement into the small amount of
> space available in the table though :-(
> 			regards, tom lane

In response to

pgsql-bugs by date

Next:From: Michael MeskesDate: 2006-03-25 11:05:41
Subject: Re: Error in ecpg
Previous:From: Tom LaneDate: 2006-03-24 21:40:58
Subject: Re: BUG #2355: Problem with INHERITS

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group