Support for weak binding views to allow dropping of underlying objects BABEL_4_X_DEV#3965
Merged
jsudrik merged 3 commits intobabelfish-for-postgresql:BABEL_4_X_DEVfrom Jul 15, 2025
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. (babelfish-for-postgresql#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: Strong binding (default): Prevents dropping referenced objects if views depend on them 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>
…e transaction snapshot Signed-off-by: Rahul Parande <rparande@amazon.com>
Collaborator
Pull Request Test Coverage Report for Build 16280640161Details
💛 - Coveralls |
jsudrik
approved these changes
Jul 15, 2025
Contributor
jsudrik
left a comment
jsudrik
left a comment
There was a problem hiding this comment.
Cherrypick from already approved and merged code.
Approved.
jsudrik
merged commit 5c9c04f
into
babelfish-for-postgresql:BABEL_4_X_DEV
48 checks passed
sharathbp
pushed a commit
to amazon-aurora/babelfish_extensions
that referenced
this pull request
Sep 22, 2025
…s BABEL_4_X_DEV (babelfish-for-postgresql#3965) * Support for weak binding views to allow dropping of underlying objects.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. (babelfish-for-postgresql#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: Strong binding (default): Prevents dropping referenced objects if views depend on them 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 * Fix crash during tuple update for broken view by registering an active transaction snapshot --------- Signed-off-by: Rahul Parande <rparande@amazon.com> Co-authored-by: Rahul Parande <rparande@amazon.com>
Yvinayak07
pushed a commit
to amazon-aurora/babelfish_extensions
that referenced
this pull request
Oct 15, 2025
…s BABEL_4_X_DEV (babelfish-for-postgresql#3965) * Support for weak binding views to allow dropping of underlying objects.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. (babelfish-for-postgresql#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: Strong binding (default): Prevents dropping referenced objects if views depend on them 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 * Fix crash during tuple update for broken view by registering an active transaction snapshot --------- Signed-off-by: Rahul Parande <rparande@amazon.com> Co-authored-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
3 participants
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.
cherry-picked from PR: #3806 and #3963
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.