Обсуждение: Wrong type for the left argument of the operator "|/" and "||/" in chapter 9.3

Поиск
Список
Период
Сортировка

Wrong type for the left argument of the operator "|/" and "||/" in chapter 9.3

От
PG Doc comments form
Дата:
The following documentation comment has been logged on the website:

Page: https://www.postgresql.org/docs/13/functions-math.html
Description:

The left argument of the operator square root |/ and cube root ||/ in the
current documentation is double precision. But to my experience that should
also work on any numeric types including smallint, integer, bigint, real and
numeric. I have tested it on both PostgreSQL server 12 and 13.

Re: Wrong type for the left argument of the operator "|/" and "||/" in chapter 9.3

От
Tom Lane
Дата:
PG Doc comments form <noreply@postgresql.org> writes:
> The left argument of the operator square root |/ and cube root ||/ in the
> current documentation is double precision. But to my experience that should
> also work on any numeric types including smallint, integer, bigint, real and
> numeric. I have tested it on both PostgreSQL server 12 and 13.

The docs are correct.  There is only one instance of these operators, and
it takes double precision, as you can easily verify in psql:

postgres=# \do |/
                                   List of operators
   Schema   | Name | Left arg type |  Right arg type  |   Result type    | Description
------------+------+---------------+------------------+------------------+-------------
 pg_catalog | |/   |               | double precision | double precision | square root
(1 row)

postgres=# \do ||/
                                   List of operators
   Schema   | Name | Left arg type |  Right arg type  |   Result type    | Description
------------+------+---------------+------------------+------------------+-------------
 pg_catalog | ||/  |               | double precision | double precision | cube root
(1 row)

The reason those other types are accepted is implicit casting, not
that the operator takes something else than what's documented.
But we're not going to clutter the function/operator tables with
annotations about what other inputs can be accepted via casts ---
it'd be bulky, repetitive, and probably more confusing than
helpful.

            regards, tom lane