From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | wgz615402729(at)live(dot)com |
Cc: | pgsql-docs(at)lists(dot)postgresql(dot)org |
Subject: | Re: Wrong type for the left argument of the operator "|/" and "||/" in chapter 9.3 |
Date: | 2021-04-28 19:58:13 |
Message-ID: | 2938565.1619639893@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs |
PG Doc comments form <noreply(at)postgresql(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | PG Doc comments form | 2021-04-29 06:32:43 | pl/pgsql errors when multi-dimensional arrays are used |
Previous Message | Laurenz Albe | 2021-04-28 18:17:49 | Re: Clarify how triggers relate to transactions |