Incident brief
Zero raised to a negative power
power(0, n) with a negative exponent is undefined because it implies division by zero, so PostgreSQL raises this data exception instead of returning infinity.
What lands in your log
ERROR: zero raised to a negative power is undefined
In 10 seconds
- What triggers it
- Call power(x, y) (or the ^ operator) with a base of exactly 0 and a negative exponent.
- Fix
- Ensure the base is non-zero whenever the exponent can be negative.
- Proof
- Reproduced on PostgreSQL 18.4 → A single SELECT reproduces SQLSTATE 2201F; the server refuses 0 raised to a negative power rather than returning infinity.
Fix
What to do right now
Application-level steps for this error.
- Ensure the base is non-zero whenever the exponent can be negative.
- Special-case a zero base (return NULL or a sentinel) before calling power().
-- Use a non-zero base when the exponent may be negative.
SELECT power(2, -1);For this error
See this error live on the server
Run these against the affected instance to confirm the diagnosis before you act.
Zero raised to a negative power (2201F) is statement-local: PostgreSQL does not retain the rejected value after the statement ends. Capture the exact bound value and statement position in application/server logs, then run this targeted validation before retrying.
Validate base/exponent together
Validate the specific value/shape that can raise this SQLSTATE.
SELECT base, exponent,
base = 0 AND exponent < 0 AS would_raise_2201F
FROM (VALUES (0::numeric, -1::numeric)) v(base, exponent);Why it happens
What PostgreSQL is telling you
The mechanism behind the error, grounded in the official manual, not paraphrased.
PostgreSQL 18 Documentation, Appendix A. PostgreSQL Error Codes (Table A.1, Class 22, Data Exception)
2201F → invalid_argument_for_power_functionRead the full section on postgresql.org →
Raising zero to a negative power
0 ^ (-1) is 1/0, which is undefined, so PostgreSQL raises 'zero raised to a negative power is undefined'.The session continues normally
This was a single failed statement, not an open transaction, so session B's next query proceeds normally with no cleanup required.Reproduce & verify
A real, single-session PostgreSQL reproduction
A literal transcript of SQL run against a live PostgreSQL instance in an isolated lab. The commands below are exactly what was executed.
- 1Call power(x, y) (or the ^ operator) with a base of exactly 0 and a negative exponent.
- 2PostgreSQL evaluates 0 ^ (-n), which is mathematically undefined because it implies 1/0.
- 3The statement aborts with SQLSTATE 2201F.
A decay formula raised a rate to a negative power and failed whenever the rate column happened to be zero for a period with no activity.
-- The error is self-contained in one statement; no schema is required.
SELECT 'no schema needed' AS setup_note;SELECT power(0, -1);SELECT 'ok' AS session_after_error;What PostgreSQL actually returned
setup_note
------------------
no schema needed
(1 row)ERROR: zero raised to a negative power is undefined session_after_error
---------------------
ok
(1 row)The same power() call succeeds once the base is guaranteed non-zero.
Without this
Before: power(0, -1) aborts
With this, tested
After: power(2, -1) returns 0.5
- A second operational test: exact SQL, raw output, measured result, and engineer notes
Card required. Cancel before day 7 and you are not charged.
Connected
Everything this error touches
Every page this SQLSTATE connects to: the concept that explains it, the runbooks that fix it, the parameters you tune to prevent it, and the sibling errors it travels with. All real cross-references. Jump straight in, or open the full interactive map.
Verification
- Last verified
- 2026-07-24 (isolated lab, PostgreSQL 18.4)
- Verification scope
- Verified against PostgreSQL 18.4 in an isolated lab environment
- Audit status
- reviewed
Went further?
Pro unlocks the second lab proof
Free page stops the bleeding. Pro adds the operational test, SQLSTATE audit, and deeper evidence, same error, more certainty.