Mark factorial operator, and postfix operators in general, as deprecated.

Per discussion, we're planning to remove parser support for postfix
operators in order to simplify the grammar.  So it behooves us to
put out a deprecation notice at least one release before that.

There is only one built-in postfix operator, ! for factorial.
Label it deprecated in the docs and in pg_description, and adjust
some examples that formerly relied on it.  (The sister prefix
operator !! is also deprecated.  We don't really have to remove
that one, but since we're suggesting that people use factorial()
instead, it seems better to remove both operators.)

Also state in the CREATE OPERATOR ref page that postfix operators
in general are going away.

Although this changes the initial contents of pg_description,
I did not force a catversion bump; it doesn't seem essential.

In v13, also back-patch 4c5cf5431, so that there's someplace for
the <link>s to point to.

Mark Dilger and John Naylor, with some adjustments by me

Discussion: https://postgr.es/m/BE2DF53D-251A-4E26-972F-930E523580E9@enterprisedb.com
This commit is contained in:
Tom Lane 2020-08-30 14:37:24 -04:00
parent 1df14a5669
commit 845cfe012f
6 changed files with 41 additions and 34 deletions

View File

@ -1055,6 +1055,7 @@ repeat('Pg', 4) <returnvalue>PgPgPgPg</returnvalue>
</para>
<para>
Factorial
(deprecated, use <link linkend="function-factorial"><function>factorial()</function></link> instead)
</para>
<para>
<literal>5 !</literal>
@ -1068,7 +1069,8 @@ repeat('Pg', 4) <returnvalue>PgPgPgPg</returnvalue>
<returnvalue>numeric</returnvalue>
</para>
<para>
Factorial (as a prefix operator)
Factorial as a prefix operator
(deprecated, use <link linkend="function-factorial"><function>factorial()</function></link> instead)
</para>
<para>
<literal>!! 5</literal>
@ -1347,6 +1349,23 @@ repeat('Pg', 4) <returnvalue>PgPgPgPg</returnvalue>
</para></entry>
</row>
<row>
<entry role="func_table_entry"><para role="func_signature">
<indexterm id="function-factorial">
<primary>factorial</primary>
</indexterm>
<function>factorial</function> ( <type>bigint</type> )
<returnvalue>numeric</returnvalue>
</para>
<para>
Factorial
</para>
<para>
<literal>factorial(5)</literal>
<returnvalue>120</returnvalue>
</para></entry>
</row>
<row>
<entry role="func_table_entry"><para role="func_signature">
<indexterm>

View File

@ -87,11 +87,18 @@ CREATE OPERATOR <replaceable>name</replaceable> (
<para>
At least one of <literal>LEFTARG</literal> and <literal>RIGHTARG</literal> must be defined. For
binary operators, both must be defined. For right unary
binary operators, both must be defined. For right unary
operators, only <literal>LEFTARG</literal> should be defined, while for left
unary operators only <literal>RIGHTARG</literal> should be defined.
</para>
<note>
<para>
Right unary, also called postfix, operators are deprecated and will be
removed in <productname>PostgreSQL</productname> version 14.
</para>
</note>
<para>
The <replaceable class="parameter">function_name</replaceable>
function must have been previously defined using <command>CREATE

View File

@ -977,27 +977,8 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
Most operators have the same precedence and are left-associative.
The precedence and associativity of the operators is hard-wired
into the parser.
</para>
<para>
You will
sometimes need to add parentheses when using combinations of
binary and unary operators. For instance:
<programlisting>
SELECT 5 ! - 6;
</programlisting>
will be parsed as:
<programlisting>
SELECT 5 ! (- 6);
</programlisting>
because the parser has no idea &mdash; until it is too late
&mdash; that <token>!</token> is defined as a postfix operator,
not an infix one. To get the desired behavior in this case, you
must write:
<programlisting>
SELECT (5 !) - 6;
</programlisting>
This is the price one pays for extensibility.
Add parentheses if you want an expression with multiple operators
to be parsed in some other way than what the precedence rules imply.
</para>
<table id="sql-precedence-table">

View File

@ -354,20 +354,19 @@ Some examples follow.
</para>
<example>
<title>Factorial Operator Type Resolution</title>
<title>Square Root Operator Type Resolution</title>
<para>
There is only one factorial operator (postfix <literal>!</literal>)
There is only one square root operator (prefix <literal>|/</literal>)
defined in the standard catalog, and it takes an argument of type
<type>bigint</type>.
<type>double precision</type>.
The scanner assigns an initial type of <type>integer</type> to the argument
in this query expression:
<screen>
SELECT 40 ! AS "40 factorial";
40 factorial
--------------------------------------------------
815915283247897734345611269596115894272000000000
SELECT |/ 40 AS "square root of 40";
square root of 40
-------------------
6.324555320336759
(1 row)
</screen>
@ -375,7 +374,7 @@ So the parser does a type conversion on the operand and the query
is equivalent to:
<screen>
SELECT CAST(40 AS bigint) ! AS "40 factorial";
SELECT |/ CAST(40 AS double precision) AS "square root of 40";
</screen>
</para>
</example>

View File

@ -218,10 +218,10 @@
oprname => '>=', oprleft => 'xid8', oprright => 'xid8', oprresult => 'bool',
oprcom => '<=(xid8,xid8)', oprnegate => '<(xid8,xid8)', oprcode => 'xid8ge',
oprrest => 'scalargesel', oprjoin => 'scalargejoinsel' },
{ oid => '388', descr => 'factorial',
{ oid => '388', descr => 'deprecated, use factorial() instead',
oprname => '!', oprkind => 'r', oprleft => 'int8', oprright => '0',
oprresult => 'numeric', oprcode => 'numeric_fac' },
{ oid => '389', descr => 'deprecated, use ! instead',
{ oid => '389', descr => 'deprecated, use factorial() instead',
oprname => '!!', oprkind => 'l', oprleft => '0', oprright => 'int8',
oprresult => 'numeric', oprcode => 'numeric_fac' },
{ oid => '385', descr => 'equal',

View File

@ -328,6 +328,7 @@
proname => 'unknownout', prorettype => 'cstring', proargtypes => 'unknown',
prosrc => 'unknownout' },
{ oid => '111',
descr => 'implementation of deprecated ! and !! factorial operators',
proname => 'numeric_fac', prorettype => 'numeric', proargtypes => 'int8',
prosrc => 'numeric_fac' },