Re: BUG #13504: Types in math functions table is incorrect

"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Thursday, July 16, 2015, <tgpfeiffer@web.de> wrote:
>> On http://www.postgresql.org/docs/9.4/static/functions-math.html in Table
>> 9-3 there is a number of issues in the "Return Type" column.
>>
>> For example:
>> - for ln it says "same as input", but the output is actually double
>> precision (both when checked with two eyes and `pg_typeof`)
>> - same for log
>> - for sign it says "same as input" but the output is actually numeric
>>
>> I have not checked all of the functions in that table, but at least the
>> ones above need to be fixed, I think.

> It would be helpful if you supplied the queries you used to make these
> determinations.

I think the OP is misreading the table and/or failing to note the
statement above it: "Many of these functions are provided in multiple
forms with different argument types. Except where noted, any given form of
a function returns the same data type as its argument."

For example, ln() comes in exactly two forms:

postgres=# \df ln
                          List of functions
   Schema   | Name | Result data type | Argument data types |  Type
------------+------+------------------+---------------------+--------
 pg_catalog | ln   | double precision | double precision    | normal
 pg_catalog | ln   | numeric          | numeric             | normal
(2 rows)

which is what the table says.

What the table does *not* say is "ln of any random numeric-category
datatype returns that same type".  This would clearly be unworkable
if the input is integer, for instance.  What actually will happen is
that the input will be cast to one of these two types and then the
function returns that type.

A more reasonable complaint would be "it's not very clear which
alternative gets picked when I pass a value that's not either
double precision or numeric".  Which is fair, because I don't think
the detailed behavior of the built-in collection of casts is really
documented anyplace.  You can infer it if you study the contents of
pg_cast, but ...

            regards, tom lane