On Mar 24, 2006, at 4:39 PM, Tom Lane wrote:
"Philip Crotwell" <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
