Avoid dumping COLLATE default for const clause

[Deepesh125]

Previously, During v2.3.0 release, we fixed the most of collatable data types such as varchar to have the correct default collation same as server_collation_name. This fix may lead to dump extra COLLATE "default" clause for const clause during upgrade from 14.x to 15.1 if server is upgrade to 14.6 via minor version upgrade first.

To fix this, we have introduced new hook handle_const_collation_hook on engine side and it would be initialised to print_const_collation inside babelfishpg_common extension which would determine if COLLATE needs to be dumped or not for given const clause.

Task: BABEL-3895
Engine PR - babelfish-for-postgresql/postgresql_modified_for_babelfish#96
Signed-off-by: Dipesh Dhameliya [email protected]

Description

[Describe what this change achieves - Guidelines below (please delete the guidelines after writing the PR description)]

1. What is the change? This is best described in terms of “Currently, Babelfish does X. With this change it now does Y.” Think of “What did it used to do?” and “What does it do now?”

2. Why was the change made? What drove our desire to put effort into the change?
3. How was the code changed should only appear for large commits. This can serve as a rough roadmap to what’s contained in the commit. It should be very high level; if it’s directly referencing code it’s probably too detailed. It’s also critical that this section of a commit message does not try to replace proper code documentation (ie, block comments or README files). Generally, this section should only appear if the commit itself is large enough that it’s helpful to provide a roadmap to someone looking at the commit.
4. The last descriptive piece is the “title” for the commit: the very first line of the commit message, which should typically be less than 80 characters. A good title is critical, because it’s the only thing that shows up in places like the Github commit listing. No one’s got time to read through full commit messages when trying to find a single commit out of dozens.

Issues Resolved

[List any issues this PR will resolve]

Test Scenarios Covered

• Use case based -

• Boundary conditions -

• Arbitrary inputs -

• Negative test cases -

• Minor version upgrade tests -

• Major version upgrade tests -

• Performance tests -

• Tooling impact -

• Client tests -

Check List

• Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is under the terms of the Apache 2.0 and PostgreSQL licenses, and grant any person obtaining a copy of the contribution permission to relicense all or a portion of my contribution to the PostgreSQL License solely to contribute all or a portion of my contribution to the PostgreSQL open source project.

For more information on following Developer Certificate of Origin and signing off your commits, please check here.