Re: Fix numeric log() with an infinite value and 0<base<=1

From: Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>
To: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Fix numeric log() with an infinite value and 0<base<=1
Date: 2026-10-14 13:57:33
Message-ID: CAEze2WjvZjNLM9YLCCCP70qXJ607Sbh6QcvoSuDt+sCtk_FxEA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 14 Oct 2026 at 13:17, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> wrote:
>
> Hi,
>
> The SQL function log() returns incorrect results in these cases:
> ```
> evantest=# SELECT log(0.5::numeric, 'Infinity'::numeric);
> log
> ----------
> Infinity
> (1 row)
>
> evantest=# SELECT log(1::numeric, 'Infinity'::numeric);
> log
> ----------
> Infinity
> (1 row)
> ```
>
> log(base, value) = ln(value) / ln(base)
>
> ln(0.5) is negative, so the first should return negative infinity; ln(1) is zero, so the second should fail with division by zero.
>
> Verifying in Python:
> ```
> >>> print(math.log(math.inf, 0.5))
> -inf
>
> >>> print(math.log(math.inf, 1));
> Traceback (most recent call last):
> File "<python-input-3>", line 1, in <module>
> print(math.log(math.inf, 1));
> ~~~~~~~~^^^^^^^^^^^^^
> ZeroDivisionError: division by zero
> ```

I don't think that we should match Python on this, because
log(non-unit-val, 1) should return a descriptive error here, and the
"division by zero" exposes implementation details that are not
relevant to the user, and indeed are quite confusing given the lack of
division operation in the user's query input. Note also that we don't
need a division by zero to determine that there is no power of 1 that
doesn't equal 1, so we shouldn't need to rely on that division.

So, I'd suggest something like

+ if (cmp_var(, const_one) == 0)
+ ereport(ERROR,
+ errcode(ERRCODE_INVALID_ARGUMENT_FOR_LOG),
+ errmsg("cannot take logarithm using base 1"));

when the base is 1; which I think is sufficiently comparable to the
checks and errors we have for non-positive value inputs.

Kind regards,

Matthias van de Meent
Databricks (https://www.databricks.com)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Aleksander Alekseev 2026-10-14 14:12:23 Re: serializable anomaly - duplicate primary keys
Previous Message Tom Lane 2026-10-14 13:39:19 Re: pg_upgrade fails with a config-only datadir and no --new-bindir