Обсуждение: BUG #2357: docs for mod() are wrong

The following bug has been logged online:

Bug reference:      2357
Logged by:          Philip Crotwell
Email address:      crotwell@seis.sc.edu
PostgreSQL version: 8.1
Operating system:   linux
Description:        docs for mod() are wrong
Details:

The docs for mod() say that the return type is "(same as argument types)"
which would seem to indicate that you could call mod() with doubles.
However, mod() with double arguments gives this error:
ERROR:  function mod(double precision, integer) does not exist

For example:
   select mod(degrees(1), 1);
ERROR:  function mod(double precision, integer) does not exist
HINT:  No function matches the given name and argument types. You may need
to add explicit type casts.

It would be nice if mod could directly take a double, but if not the docs
should say that the arguments should be NUMERIC and you must cast, for
example this works:
   select mod(CAST (degrees(1) AS NUMERIC), 1);

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

> 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

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