error codes for ln(), power()
SQL2003 mandates that ln() and power() emit particular SQLSTATE error
codes for a few illegal combinations of arguments (in Section 6.27 of my
copy of SQL2003). This patch adds those error codes and changes the
several variants of ln() and power() to emit them as appropriate.
I didn't change log() to emit the same error code as ln() when it is
passed similarly incorrect arguments, on the grounds that the SQLSTATE
code defined by SQL specifically refers to the "natural logarithm". Does
anyone think I should make both log() and ln() return the same SQLSTATE
code, invent a new SQLSTATE for log() errors, and just leave things as
they are? (the latter being my preference...)
I didn't bother adding any regression tests for this behavior, but I can
do so if anyone thinks that's worth doing.
Barring any objections, I intend to apply this patch within 24 hours.
-Neil
Attachments:
numeric-func-errcodes-1.patchtext/x-patch; charset=ANSI_X3.4-1968; name=numeric-func-errcodes-1.patchDownload+60-19
Neil Conway <neilc@samurai.com> writes:
I didn't change log() to emit the same error code as ln() when it is
passed similarly incorrect arguments, on the grounds that the SQLSTATE
code defined by SQL specifically refers to the "natural logarithm". Does
anyone think I should make both log() and ln() return the same SQLSTATE
code, invent a new SQLSTATE for log() errors, and just leave things as
they are? (the latter being my preference...)
But the spec hasn't even got log(), so it can hardly be thought to be
taking a position on what error codes log() should return. I think
log() should use the same error codes as ln(). Otherwise you're
essentially arguing that SQL-extension functions should never use
relevant codes defined by the standard because that is usage outside the
scope of the standard. That leads to massive invention of SQLSTATE
codes, which is hardly what we want. Certainly there are other places
where we've slightly expanded the meaning of a spec-defined code.
You might consider changing the explication of the state code to INVALID
ARGUMENT FOR LOGARITHM, omitting the word NATURAL.
+ if ((arg1 == 0 && arg2 < 0) ||
+ (arg1 < 0 && trunc(arg2) != arg2))
I don't think trunc() is portable ... we certainly don't use it anywhere
else. May I suggest rint() instead? Or floor()?
regards, tom lane
On Sat, 2004-05-15 at 11:52, Tom Lane wrote:
But the spec hasn't even got log(), so it can hardly be thought to be
taking a position on what error codes log() should return. I think
log() should use the same error codes as ln().
Point taken, I've made this change.
You might consider changing the explication of the state code to INVALID
ARGUMENT FOR LOGARITHM, omitting the word NATURAL.
Done.
I don't think trunc() is portable ... we certainly don't use it anywhere
else. May I suggest rint() instead? Or floor()?
trunc() is C99, but we may as well use floor(), which is C89.
I've attached a revised patch. It incorporates your suggestions, and
makes one additional change: the SQL standard defines sqrt(x) as
power(x, 0.5) -- therefore, ISTM that sqrt(-whatever) should emit the
"invalid argument to power function" SQLSTATE code.
Barring any objections, I'll apply this patch tonight (... or as soon as
CVS is back up).
-Neil