As for the param types. How do we enforce these? If we have a lazy simple serde and a varchar 10 and we are reading a column with 11 chars, what do we do?
Maybe we say that char is an alias and we do not actually enforce anything. On Tuesday, July 30, 2013, Xuefu Zhang (JIRA) <j...@apache.org> wrote: > > [ https://issues.apache.org/jira/browse/HIVE-4844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13724626#comment-13724626] > > Xuefu Zhang commented on HIVE-4844: > ----------------------------------- > > [~jdere] Thanks for sharing your work. I went thru your patch and had some initial questions. I understand that your patch is still in progress, but I'm wondering what's your thought on how you plan to store the type params. Obviously, type params are metadata of a column, which needs to be stored. I assume that hive schema needs to change to accommodate this. > > Secondly, SQL VAR or VARCHAR seems to be special hive string with additional restriction. Your patch seems treating them independently. Do you think if type inheritance works here? > > Lastly, introducing param types seems non-trivial. Do you think if a design doc or wiki page makes sense? > >> Add char/varchar data types >> --------------------------- >> >> Key: HIVE-4844 >> URL: https://issues.apache.org/jira/browse/HIVE-4844 >> Project: Hive >> Issue Type: New Feature >> Components: Types >> Reporter: Jason Dere >> Assignee: Jason Dere >> Attachments: HIVE-4844.1.patch.hack >> >> >> Add new char/varchar data types which have support for more SQL-compliant behavior, such as SQL string comparison semantics, max length, etc. > > -- > This message is automatically generated by JIRA. > If you think it was sent incorrectly, please contact your JIRA administrators > For more information on JIRA, see: http://www.atlassian.com/software/jira >
