Support for weak binding views to allow dropping of underlying objects#3955
Closed
R4hul04 wants to merge 1 commit intobabelfish-for-postgresql:BABEL_5_3_STABLEfrom
Closed
Support for weak binding views to allow dropping of underlying objects#3955R4hul04 wants to merge 1 commit intobabelfish-for-postgresql:BABEL_5_3_STABLEfrom
R4hul04 wants to merge 1 commit intobabelfish-for-postgresql:BABEL_5_3_STABLEfrom
Conversation
…s.This commit introduces support for both strong and weak view binding in Babelfish, aligning more closely with SQL Server's default behavior while maintaining flexibility. Key changes: - Introduce GUC parameter 'babelfishpg_tsql.weak_view_binding' to control default binding behavior (default: false) - Support explicit WITH SCHEMABINDING clause for strong binding - Implement weak binding to allow dropping of referenced objects - Handle ALTER VIEW operations in both binding modes - Add logic to repair broken views when underlying objects are recreated Limitations: - Only addresses DROP operations on tables, views, functions, and procedures - ALTER TABLE/ALTER FUNCTION operations still restricted when dependent views exist - View repair follows PostgreSQL's CREATE OR REPLACE VIEW restrictions Signed-off-by: Rahul Parande <rparande@amazon.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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:
This feature aligns Babelfish more closely with SQL Server's behavior, providing greater flexibility
Key aspects include:
babelfishpg_tsql.weak_view_bindingto control the default binding behavior (default is false)WITH SCHEMABINDINGto create strongly bound views regardless of the GUC settingALTER VIEWoperations in both binding modesIn 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
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
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.