sql: revisit the typing RFC in the light of sql2011

[knz]

Found in a comment on #1795:

While SQL:2011 basically leaves much of this as an implementation detail ...

"Every number has a precision (number of digits), and exact numeric types also have a scale (digits after the radix point). Arithmetic operations may be performed on operands of different or the same numeric type, and the result is of a numeric type that depends only on the numeric type of the operands. If the result cannot be represented exactly in the result type, then whether it is rounded or truncated is implementation-defined. An exception condition is raised if the result is outside the range of numeric values of the result type, or if the arithmetic operation is not defined for the operands."

The new typing system might need to make more efforts depending on how much the standard specifies. One should read the standard and see if the RFC conflicts, then adapt accordingly.

[petermattis]

I'm having trouble determining what the text you quoted precludes in the typing RFC. And there is also the question of whether being compliant to the SQL:2011 spec is a goal. Unlike other standards, it seems the compliance to the SQL spec is much looser, with quite a bit left to implementation detail.

[knz]

OK but I think it's fair to create a doc that acknowledges how we diverge from the standard. That's why I want to read it through and see if there's anything noteworthy in there.

[petermattis]

Agreed that we should be cognizant of where we diverge from the standard and to document such occurrences.

[knz]

So @nvanbenschoten and I (mostly nathan) have looked at the spec and observed that it is largely silent about what needs to be done. The only item of note is that it strongly recommends that anything can be compared to anything, which we may not fully support yet. Other than that implementations are largely free to innovate.