Skip site navigation (1) Skip section navigation (2)

Re: pgsql: Have numeric 0 ^ 4.3 return 1, rather than an error, and have 0 ^

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-committers(at)postgresql(dot)org
Subject: Re: pgsql: Have numeric 0 ^ 4.3 return 1, rather than an error, and have 0 ^
Date: 2008-05-09 15:36:07
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-committers
Tom Lane wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> > Wikipedia says that exponentiation of zero to a negative power implies
> > division by zero, so shouldn't we throw a "division by zero" error?
> I think it should be a specific message like "zero raised to a negative
> power is undefined".  It's not like it's going to take us any extra code
> to know that we are faced with that case.
> BTW, I realized that SQL:2003 spells it all out for us in explicit
> detail:


> b) If VB is 0 (zero) and VE is negative, then an exception condition is
> raised: data exception  invalid argument for power function.

Well, this indicates we shouldn't return "zero raised to a negative
power is undefined", but rather the power error we are giving now, or
are you saying we should return the "power" error code but an error
message mentioning zero?

> c) If VB is 0 (zero) and VE is 0 (zero), then the result is 1 (one). 

I have updated the C comments to mention the spec also requires we
return 1 in this case.

C comment updated attached and applied.

  Bruce Momjian  <bruce(at)momjian(dot)us>

  + If your life is a hard drive, Christ can be your backup. +

Attachment: /rtmp/diff
Description: text/x-diff (2.1 KB)

In response to


pgsql-committers by date

Next:From: Peter EisentrautDate: 2008-05-09 15:36:31
Subject: pgsql: Add "%option noinput" to the scanners to avoid compiler warnings.
Previous:From: Bruce MomjianDate: 2008-05-09 15:36:06
Subject: pgsql: Update C comments to mention SQL:2003 handling of power return

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group