bq. by recognizing existing tables with "." as part of the default namespace or automatically create namespaces for tables with dots in them.
I think putting existing tables with "." in table name as part of default namespace is better choice among the two. Cheers On Wed, May 8, 2013 at 5:02 PM, Francis Liu <[email protected]> wrote: > There shouldn't be any ambiguity. There's fully-qualified table names and > there's table names. Table name constant changes were to make the names > less funky. > > I like your suggestion since it simplifies migration. Though it seems > we're kicking the can down the road here. In a way we're avoiding the > problem by specifying an internal delimiter and adding extra complexity to > prevent the user from using it. Having a way of specifying a table fully > qualified seems to be something fundamental and convenient, if we don't > support one now we'll have even more trouble in the future. Looking at the > suggestions we can potentially make migration painless by recognizing > existing tables with "." as part of the default namespace or automatically > create namespaces for tables with dots in them. Neither requires renaming > tables. They only need to rename tables if they want to start organizing > things into namespaces which they will have to do in any scenario. > > -Francis > > On May 8, 2013, at 1:27 PM, Elliott Clark wrote: > > > With this solution there's no naming ambiguity. There's no > > overloading table name to actually be two different things. There's > > no need for users to rename their tables. Most code that is already > > written will still be source compatible. No need to change table name > > constants or anything like that. > > > >
