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
