Thanks for clarifying your question.
If the comment is about
HIVE-5564, I think it might be better to move the discussion there. Nevertheless, as short response to your comments:
1. The question of backward compatibility was brought up in day 1, and detailed in the functional document. I think there is an agreement that no known customer is seriously using decimal, and break of the backward compatibility isn't a concern for this project. Unless you want to bring up that discussion again, let's move forward without further concerning.
2. Internally, typeinfo object for "decimal(65,30)" is not user facing, (i.e, when specifying column type), but for internal default when serve doesn't know the type (for instance, the decimal type returned by non-generic udf). To further clarify, externally user specifying "decimal" for column name, server interprets it as "decimal(10, 0)"; internally, if server cannot determine the exact type, then decimal(65,30) is assumed.
3. In my opinion, fixing the error in
HIVE-5564 is better than assuming (65,30) as the user default due to its usability problem. BTW, the fix could have been included in this patch, so the "error" would not have come in the picture at all.
I think I should put the clarification in #2 in the document as well. Let me know if you have more questions.