回复： 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"                          
                                                          
<t...@sss.pgh.pa.us&gt;;
发送时间:&nbsp;2021年11月12日(星期五) 中午1:42
收件人:&nbsp;"孤傲小二～阿沐"<2903807...@qq.com&gt;;
抄送:&nbsp;"pgsql-general"<pgsql-general@lists.postgresql.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=?=" <2903807...@qq.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