HIVE-29413: Avoid code duplication by updating getPartCols method for iceberg tables

[ramitg254]

What changes were proposed in this pull request?

added getEffectivePartCols() in most places possible to avoid code duplication.

Why are the changes needed?

getPartCols() does not have support for iceberg tables.

Does this PR introduce any user-facing change?

No

How was this patch tested?

ci tests and local build

[deniskuzZ]

@ramitg254 please take a look: 9e7535c. I would suggest following similar approach

[ramitg254]

9e7535c

but here we are creating separate method getEffectivePartCols() and leaving getPartCols() as it is, which as per our discussion on that closed pr we shouldn't do that, and only go ahead with updating getPartCols()

[deniskuzZ]

9e7535c

but here we are creating separate method getEffectivePartCols() and leaving getPartCols() as it is, which as per our discussion on that closed pr we shouldn't do that, and only go ahead with updating getPartCols()

Where did I say that? The ask was to keep the original method unchanged. same here

[ramitg254]

oh I got confused due to this comment: #6337 (comment) in which getSupportedPartCols() was just separate method similar to getEffectivePartCols()

[ramitg254]

I am fine with that earlier approach as well but recently I saw this one: https://issues.apache.org/jira/browse/HIVE-29525 so I thought we should have unified getPartCols() and getCols() which gives similar results as native hive tables as first step towards solving this after that those plan logics can be taken care of later on when that ticket will be addressed.
So I was first focussing on making getPartCols() unified for iceberg tables as well.

please share your thoughts on this idea

[ramitg254]

@deniskuzZ please review this patch
replaced getPartCols() with getEffectivePartCols() wherever possible and kept getPartCols() in places where hack was needed to use getEffectivePartCols()
changes were made keeping this in mind that we should reduce usage of getPartCols() anywhere possible so that both methods can be merged to one later on in future
refractor is also done and will address sonar issues along with the changes if needed

[ramitg254]

these indentations issues which sonar pointed out doesn't make sense because if I'll change the indentation of case statements from 6 to 4 then then will align with return statement as it is at indentation 4 so keeping it as it is and ignoring those and addressed all the others which were pointed earlier

[sonarqubecloud]

Quality Gate passed

Issues
8 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.8% Duplication on New Code

See analysis details on SonarQube Cloud