[akmhatey-ai]

Which issue does this PR close?

• Closes PostgreSQL compatibility: ln(-1.0::float8) should error, not return NaN #22271.

Rationale for this change

DataFusion currently returns NaN for negative ln inputs. PostgreSQL raises an error for the same case, and issue #22271 tracks aligning ln((-1.0)::float8) with that behavior.

This keeps the existing ln(0) behavior unchanged.

What changes are included in this PR?

• Move ln from the shared unary math macro to a dedicated LnFunc implementation.
• Return a compute error when ln receives a negative Float32 or Float64 value.
• Update scalar.slt to cover positive column inputs plus negative scalar and column error cases.

Are these changes tested?

Yes. I ran:

• cargo fmt --check -- datafusion/functions/src/math/mod.rs datafusion/functions/src/math/ln.rs
• cargo check -p datafusion-functions
• cargo test -p datafusion-functions math::ln --lib
• cargo test -p datafusion-sqllogictest --test sqllogictests -- scalar:586
• cargo test -p datafusion-sqllogictest --test sqllogictests -- scalar:593
• cargo test -p datafusion-sqllogictest --test sqllogictests -- scalar:597
• git diff --check

I also ran cargo test -p datafusion-sqllogictest --test sqllogictests -- scalar. The changed ln records passed, but the full file failed later at scalar.slt:1546+ because local aggregate_test_100 data was empty in this checkout; those failures were unrelated to this change.

Are there any user-facing changes?

Yes. ln now errors on negative inputs instead of returning NaN.

[kumarUjjawal]

I think we also need to look into other such log functions which also return NaN.

DataFusion CLI v53.1.0
> >   SELECT
    ln(2.0)    AS ln_pos,
    log10(100.0) AS log10_pos,
    log(-1.0)    AS log_neg,
    log2(-1.0)   AS log2_neg,
    log10(-1.0)  AS log10_neg;
+--------------------+-----------+---------+----------+-----------+
| ln_pos             | log10_pos | log_neg | log2_neg | log10_neg |
+--------------------+-----------+---------+----------+-----------+
| 0.6931471805599453 | 2.0       | NaN     | NaN      | NaN       |
+--------------------+-----------+---------+----------+-----------+
1 row(s) fetched.
Elapsed 0.004 seconds.

[kumarUjjawal]

We don't need a new file for the ln we can extend the already available macro for this.

[akmhatey-ai]

Updated in 48152f0.

Covered the other negative-input cases from your example:

• log now rejects negative values for float and decimal inputs.
• log2 and log10 now use checked unary handling for negative Float32/Float64 inputs.
• Invalid bases are unchanged and still follow the existing NaN behavior.

Validation run:

• cargo test -p datafusion-functions test_log -- --nocapture
• cargo test -p datafusion-sqllogictest --test sqllogictests -- scalar:640
• cargo test -p datafusion-sqllogictest --test sqllogictests -- scalar:662
• cargo test -p datafusion-sqllogictest --test sqllogictests -- scalar:711
• cargo test -p datafusion-sqllogictest --test sqllogictests -- scalar:722
• cargo test -p datafusion-sqllogictest --test sqllogictests -- scalar:750
• cargo test -p datafusion-sqllogictest --test sqllogictests -- scalar:761
• rustfmt --check datafusion/functions/src/math/log.rs datafusion/functions/src/macros.rs datafusion/functions/src/math/mod.rs
• git diff --check
• gitleaks detect --no-git on the changed files

One limitation: full cargo test -p datafusion-sqllogictest --test sqllogictests -- scalar still fails later on existing aggregate_test_100 expectations around lines 1551-1600, outside this log change.

[kumarUjjawal]

Can you also look into the power usage of log?

[kumarUjjawal]

This rewrite can skip the new error. log(-2.0, power(-2.0, 3.0)) should error because the log value is negative, but this can simplify to 3.0. Please only rewrite when the log domain is proven valid.

[kumarUjjawal]

This rewrite can skip the new error. log(-2.0, -2.0) should error, but this can simplify to 1. Please keep the original expression unless the value and base are proven valid

[github-actions]

Thank you for your contribution. Unfortunately, this pull request is stale because it has been open 60 days with no activity. Please remove the stale label or comment or this will be closed in 7 days.