BUG #13504: Types in math functions table is incorrect

On Thursday, July 16, 2015, <tgpfeiffer@web.de> wrote:

The following bug has been logged on the website:

Bug reference: 13504
Logged by: Tobias Pfeiffer
Email address: tgpfeiffer@web.de <javascript:;>
PostgreSQL version: 9.4.4
Operating system: --
Description:

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.

David J.

"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

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Hi,

On Fri, 17 Jul 2015 12:24:51 -0400 Tom Lane wrote:

"David G. Johnston" <david.g.johnston@gmail.com> writes:

On Thursday, July 16, 2015, <tgpfeiffer@web.de> wrote:

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

Ah, yes, that's exactly what happened...

[...]
What the table does *not* say is "ln of any random numeric-category
datatype returns that same type".

That's what I read out of it, I was somehow assuming "numeric"
describes a "random numeric-category". Sorry, my mistake.

Kind regards,
Tobias