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
Show quoted text
but if not the docs
should say that the arguments should be NUMERICThat 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