The first thing that comes to my mind is that this would limit functionality when defining views on existing raw HBase tables (though aliasing the columns may solve that) Another thing to consider is how this would affect dynamic column use cases for either native Phoenix tables of views on HBase tables.
Istvan On Sat, Mar 27, 2021 at 12:20 AM [email protected] <[email protected]> wrote: > As you may or may not know, Phoenix allows for duplicate column names as > long as they are placed in different column families. > > You can create a table such as CREATE TABLE t (pk1 ..., x.v1, y.v1, ...). > Now each time you want to refer to v1 you need to qualify it with its > column family or you get a AmbiguousColumnException. > > Worse, you also do CREATE TABLE t (pk1 ..., v1, x.v1, ...). Now a using v1 > in a query will silently resolve to v1 in the default column family and > x.v1 does have to be qualified. > > As I reason through how this should work in Trino's (formerly Presto) > Phoenix connector, it occurs to me that should probably just disallow this. > > CREATE TABLE t (pk1 ..., x.v1, y.v2, ...) works just fine and you can > refer to both v1 and v2 without the need to qualify them with the column > family. > > So... In essence: Should we require all columns to be uniquely named, even > with multiple column families? > > Thanks. > > -- Lars > -- *István Tóth* | Staff Software Engineer [email protected] <https://www.cloudera.com> [image: Cloudera] <https://www.cloudera.com/> [image: Cloudera on Twitter] <https://twitter.com/cloudera> [image: Cloudera on Facebook] <https://www.facebook.com/cloudera> [image: Cloudera on LinkedIn] <https://www.linkedin.com/company/cloudera> <https://www.cloudera.com/> ------------------------------
