回复： I added a √ operator, the sqrt function is still used internally, but now there is a problem, it affects the := and .. operators of the database

Hello, I think what you said is right, it should be the problem. But I don't know what to do in the lexical analysis system of plpgsql to solve this problem.

------------------ 原始邮件 ------------------
发件人: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us&gt;;
发送时间:&nbsp;2021年11月12日(星期五) 中午1:42
收件人:&nbsp;"孤傲小二～阿沐"<2903807914(at)qq(dot)com&gt;;
抄送:&nbsp;"pgsql-general"<pgsql-general(at)lists(dot)postgresql(dot)org&gt;;
主题:&nbsp;Re: I added a √ operator, the sqrt function is still used internally, but now there is a problem, it affects the := and .. operators of the database

"=?gb18030?B?ucKwwdChtv6hq7Ci4+U=?=" <2903807914(at)qq(dot)com&gt; writes:
&gt; # Description of Requirement:
&gt; 1¡¢select ¡Ì num1; function
&gt; 2¡¢The value of num1 is required to be: [0,9223372036854775807]
&gt; 3¡¢¡Ì The operation does not allow decimals

Looks suspiciously like a homework assignment.

&gt; I have now developed this feature on the PostgreSQL 14.0 kernel! But it affects the original function of the database:
&gt; #&amp;nbsp;Affected place
&gt; 1¡¢ := assignment operator
&gt; 2¡¢ Operator in 1..10

Today's lesson is: read the comments on the code you're modifying.
Notably on gram.y's list of "non keyword" tokens:

&nbsp;* Non-keyword token types.&nbsp; These are hard-wired into the "flex" lexer.
&nbsp;* They must be listed first so that their numeric codes do not depend on
&nbsp;* the set of keywords.&nbsp; PL/pgSQL depends on this so that it can share the
&nbsp;* same lexer.&nbsp; If you add/change tokens here, fix PL/pgSQL to match!

Since you didn't do that, PL/pgSQL is confused about the token codes
in use for DOT_DOT and so on.

regards, tom lane