feat(expr): support for sqrt function

[lyang24]

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.

fixes: #8899

What's changed and what's your intention?

enable the the sqrt calculation of a decimal or a float.
according to postgres doc sqrt function can take either numeric or double precisions

sqrt ( numeric ) → numeric

sqrt ( double precision ) → double precision

Square root

sqrt(2) → 1.4142135623730951

Checklist For Contributors

• I have written necessary rustdoc comments
• I have added necessary unit tests and integration tests
• I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features Sqlsmith: Sql feature generation #7934).
• I have demonstrated that backward compatibility is not broken by breaking changes and created issues to track deprecated features to be removed in the future. (Please refer to the issue)
• All checks passed in ./risedev check (or alias, ./risedev c)

Checklist For Reviewers

• I have requested macro/micro-benchmarks as this PR can affect performance substantially, and the results are shown.

Documentation

• My PR DOES NOT contain user-facing changes.

Click here for Documentation

Types of user-facing changes

Please keep the types that apply to your changes, and remove the others.

• Installation and deployment
• Connector (sources & sinks)
• SQL commands, functions, and operators
• RisingWave cluster configuration changes
• Other (please specify in the release note below)

Release note

[xxchan]

Hi @lyang24 , Thanks for your contribution! You can make the PR ready to review to run CI (You might need to push a new commit or update the brunch to trigger it)

BTW, the unary operator PGSquareRoot is not yet implemented, so I think the float8.sql test will fail.

[lyang24]

Hi @lyang24 , Thanks for your contribution! You can make the PR ready to review to run CI (You might need to push a new commit or update the brunch to trigger it)

BTW, the unary operator PGSquareRoot is not yet implemented, so I think the float8.sql test will fail.

good catch added unary operator support for sqrt and formatted the code - please take another look.

[xxchan]

Generally LGTM. But it seems test failed due to precision issue. cc @xiangjinwu I remember it happened before. Do you have any references?

[lyang24]

how do we derived the expected out put? in src/tests/regress/data/expected/float8.out it is from postgres? can we modify this section to avoid test failing due to percisions

[xiangjinwu]

Rest lgtm. Thanks for your contribution

[xiangjinwu]

Let's use an explicit cast to double precision or keep it quoted, so that it is testing 64-bit float rather than numeric (aka decimal).

FYI PostgreSQL's rules of typing:

select pg_typeof(sqrt('1004.3')), pg_typeof('1004.3')
union all
select pg_typeof(sqrt(1004.3)), pg_typeof(1004.3)
union all
select pg_typeof(sqrt(25)), pg_typeof(25)
;

    pg_typeof     | pg_typeof 
------------------+-----------
 double precision | unknown
 numeric          | numeric
 double precision | integer
(3 rows)

That is, there are 2 versions of sqrt function, one for double precision and one for numeric, as #8899 listed. In PostgreSQL, it prefers the double precision version unless the input is numeric, and 1004.3 without quotes is considered numeric.

Here we only have one version handling double precision, so it is chosen to handle 1004.3 as well. This test would be testing a different thing when we add the second version. And, we can now add sqrt(numeric) too if you'd like, given #9043 is merged.

[lyang24]

added support and test for sqrt(numeric)

[lyang24]

I would like to merge the logic branch so the error is not duplicated.
not sure if its possible to merge match branch like below

Decimal::Normalized(value) if let some(res) = value.sqrt() => {
      ...
}
_ => {
      ...
}

[xiangjinwu]

I am not sure if is possible to match-sqrt-match with a single match either.

[xiangjinwu]

nit: we do not need db-postgres for expr.

[xiangjinwu]

I am not sure if is possible to match-sqrt-match with a single match either.

[xiangjinwu]

Thanks for your contribution!