Support for weak binding views to allow dropping of underlying objects 5_3_STABLE

[R4hul04]

Cherry picked commit from: #3806

Description

Currently, Babelfish only supports strong binding for views, which prevents dropping or altering referenced objects when views depend on them. This behavior differs from SQL Server, which by default allows dropping underlying tables or views unless WITH SCHEMABINDING is explicitly specified.
With this change, Babelfish now supports configurable view binding modes:

1. Strong binding (default): Prevents dropping referenced objects if views depend on them
2. Weak binding: Allows dropping of referenced objects

This feature aligns Babelfish more closely with SQL Server's behavior, providing greater flexibility
Key aspects include:

• A new GUC parameter babelfishpg_tsql.weak_view_binding to control the default binding behavior (default is false)
• Support for explicit WITH SCHEMABINDING to create strongly bound views regardless of the GUC setting
• Ability to create weakly bound views by default when the GUC is enabled
• Proper handling of ALTER VIEW operations in both binding modes

In SQL Server, views are weakly bound by default, allowing underlying objects to be dropped or altered. With our implementation, users can now choose between SQL Server's default behavior (weak binding) or the previously enforced behavior (strong binding).

Important Limitation :

This implementation currently only addresses DROP operations on tables, views, functions, procedures as well as ALTER operations on views when these objects are bound by dependent views. ALTER TABLE/ ALTER FUNCTION operations (such as dropping columns or changing data types) are still restricted when dependent views exist, regardless of binding mode. This differs from SQL Server's behavior, where weak binding also allows ALTER operations on referenced objects.
When the same underlying object is recreated, its broken child view will get repaired only if it follows postgresql restrictions for CREATE OR REPLACE VIEW. [The new query must generate the same columns that were generated by the existing view query (that is, the same column names in the same order and with the same data types), but it may add additional columns to the end of the list]
https://www.postgresql.org/docs/current/sql-createview.html#:~:text=The%20new%20query,be%20completely%20different.

Issues Resolved

BABEL-1660

Signed-off-by: Rahul Parande rparande@amazon.com

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.

[coveralls]

Pull Request Test Coverage Report for Build 16233431322

Details

• 359 of 388 (92.53%) changed or added relevant lines in 7 files are covered.
• 2 unchanged lines in 1 file lost coverage.
• Overall coverage increased (+0.09%) to 75.638%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
contrib/babelfishpg_tsql/src/catalog.c	22	28	78.57%
contrib/babelfishpg_tsql/src/hooks.c	301	324	92.9%

Files with Coverage Reduction	New Missed Lines	%
contrib/babelfishpg_tds/src/backend/tds/tdscomm.c	2	76.16%

Totals
Change from base Build 16168306610:	0.09%
Covered Lines:	49644
Relevant Lines:	65634

---

💛 - Coveralls