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
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t135757psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 27, 2026 at 03:52 PM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t135757_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t135757_1 && git checkout t135757_1Patchset v1 (message #1) is on t135757_1
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; function
2、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
"=?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:
> #&nbsp;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
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.