dbTalk Databases Forums  

[BUGS] BUG #2357: docs for mod() are wrong

mailing.database.pgsql-bugs mailing.database.pgsql-bugs


Discuss [BUGS] BUG #2357: docs for mod() are wrong in the mailing.database.pgsql-bugs forum.



Reply
 
Thread Tools Display Modes
  #1  
Old   
Philip Crotwell
 
Posts: n/a

Default [BUGS] BUG #2357: docs for mod() are wrong - 03-24-2006 , 03:22 PM







The following bug has been logged online:

Bug reference: 2357
Logged by: Philip Crotwell
Email address: crotwell (AT) seis (DOT) 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);

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Reply With Quote
  #2  
Old   
Tom Lane
 
Posts: n/a

Default Re: [BUGS] BUG #2357: docs for mod() are wrong - 03-24-2006 , 03:40 PM






"Philip Crotwell" <crotwell (AT) seis (DOT) sc.edu> writes:
Quote:
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?

Quote:
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 5: don't forget to increase your free space map settings


Reply With Quote
  #3  
Old   
Philip Crotwell
 
Posts: n/a

Default Re: [BUGS] BUG #2357: docs for mod() are wrong - 03-26-2006 , 07:50 PM




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

Quote:
"Philip Crotwell" <crotwell (AT) seis (DOT) 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

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


Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.