I'm not convinced that this assignment is a good idea.
I see that it makes the signature a little simpler to pass a TupleValueExpression if the caller has one handy -- but there is one case where it does not have one and it has to build one, so that cancels some of the benefits.
Also, if you change a signature, change the javadoc comments.
And whether we originally have a TVE or we have to build one, the TVE always turns out to be a little bit wrong because the caller of getPartitionColumn() really wants a TVE with the correct tableAlias -- maybe the caller should pass in the alias that they want and we can build/clone a TVE for them internally upon request.
But actually saving one TVE and providing an accessor that returns only one TVE does not seem like it is enough to cover all cases. If both a third level subquery and its parent subquery are partition key joins with a "select *", the middle subquery has _2_ or more child TVEs that it can use internally for filtering or joining. Then the middle subquery has _3_ or more child TVEs that the top-level parent can use for filtering or joining. Picking one TVE at each level does not seem useful. In contrast, picking one "m_fullColumnName" is OK (I think) because (if it is ever used?) it is only used to print a warning with one example of what might work as a partition key.
I think that getPartitionColumn needs to be getPartitioningColumns (plural) and needs to expose some details of the equivalenceSet? -- but isn't that what findPartitioningColumns is all about? It looks like this needs refactoring.