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

On Mar 24, 2006, at 4:39 PM, Tom Lane wrote:

> "Philip Crotwell" <crotwell@seis.sc.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,
360)
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.

thanks,
Philip

>
>> 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