Обсуждение: 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 everyone，
I added a √ operator to scan.l. The sqrt function is still used internally, but there is a problem now, which affects the := and .. operators of the database.
# Description of Requirement:
1、select √ num1; function
2、The value of num1 is required to be: [0,9223372036854775807]
3、√ The operation does not allow decimals
I have now developed this feature on the PostgreSQL 14.0 kernel! But it affects the original function of the database:
# Affected place
1、 := assignment operator
2、 Operator in 1..10
# Recurring problem
1、make check
Вложения
On Thu, Nov 11, 2021 at 8:42 PM 孤傲小二～阿沐 <2903807914@qq.com> wrote:
I added a √ operator to scan.l.
Why?
The sqrt function is still used internally, but there is a problem now, which affects the := and .. operators of the database.
Someone else will have to volunteer their time to cover this learning curve (I couldn't even if I wanted to). But given that what you are trying to accomplish is not something we'd likely consider adding to the core server (we created CREATE OPERATOR instead) that seems like a bit of an ask.
# Description of Requirement:1、select √ num1; function2、The value of num1 is required to be: [0,9223372036854775807]3、√ The operation does not allow decimals
Per 2 the value of num1 is a decimal yet per 3 the operation is required to not allow decimals?
David J.
"=?gb18030?B?ucKwwdChtv6hq7Ci4+U=?=" <2903807914@qq.com> writes:
> # Description of Requirement:
> 1¡¢select ¡Ì num1; function
> 2¡¢The value of num1 is required to be: [0,9223372036854775807]
> 3¡¢¡Ì The operation does not allow decimals
Looks suspiciously like a homework assignment.
> I have now developed this feature on the PostgreSQL 14.0 kernel! But it affects the original function of the
database:
> # Affected place
> 1¡¢ := assignment operator
> 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:
* Non-keyword token types. These are hard-wired into the "flex" lexer.
* They must be listed first so that their numeric codes do not depend on
* the set of keywords. PL/pgSQL depends on this so that it can share the
* same lexer. 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
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@sss.pgh.pa.us>;
发送时间: 2021年11月12日(星期五) 中午1:42
收件人: "孤傲小二～阿沐"<2903807914@qq.com>;
抄送: "pgsql-general"<pgsql-general@lists.postgresql.org>;
主题: 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
> # Description of Requirement:
> 1¡¢select ¡Ì num1; function
> 2¡¢The value of num1 is required to be: [0,9223372036854775807]
> 3¡¢¡Ì The operation does not allow decimals
Looks suspiciously like a homework assignment.
> I have now developed this feature on the PostgreSQL 14.0 kernel! But it affects the original function of the database:
> # Affected place
> 1¡¢ := assignment operator
> 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:
* Non-keyword token types. These are hard-wired into the "flex" lexer.
* They must be listed first so that their numeric codes do not depend on
* the set of keywords. PL/pgSQL depends on this so that it can share the
* same lexer. 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
On Thursday, November 11, 2021, 孤傲小二～阿沐 <2903807914@qq.com> wrote:
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.
“To match” means keep two copies identical, in this case manually. Try grepping for the pre-change line you are modifying to see where its twin is.
David J.
Hello everyone, I modified src/fe_utils/psqlscan.l src/interfaces/ecpg/preproc/pgc.l src/pl/plpgsql/src/pl_gram.y according to his suggestion to keep scan.l gram.y consistent , But still error
------------------ 原始邮件 ------------------
发件人: "David G. Johnston" <david.g.johnston@gmail.com>;
发送时间: 2021年11月12日(星期五) 下午2:09
收件人: "孤傲小二～阿沐"<2903807914@qq.com>;
抄送: "Tom Lane"<tgl@sss.pgh.pa.us>;"pgsql-general"<pgsql-general@lists.postgresql.org>;
主题: 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
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.
“To match” means keep two copies identical, in this case manually. Try grepping for the pre-change line you are modifying to see where its twin is.
David J.