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

From: Philip Crotwell Tom Lane pgsql-bugs(at)postgresql(dot)org Re: BUG #2357: docs for mod() are wrong 2006-03-25 01:07:23 01ac6ab17e113c7921e8cf2eb0def35c@seis.sc.edu (view raw, whole thread or download thread mbox) 2006-03-24 17:00:44 from "Philip Crotwell"  2006-03-24 21:39:20 from Tom Lane   2006-03-25 01:07:23 from Philip Crotwell 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,
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

```

### pgsql-bugs by date

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