Avoid storing initial privileges for Babelfish objects created during initialization

[HarshLunagariya]

Description

In Babelfish, Currently There are two patterns followed for initial privileges for system created objects:

1. Initial privileges are stored for the objects that are created during CREATE EXTENSION like system object, catalogs.
2. But for the objects that are created during initialize_babelfish() (which gets executed after creating extension) like dbo user, schema for system generated TSQL databases like master, msdb, tempdb, Initial privileges are not being recorded.

When there are any GRANT/REVOKE on objects which are created during initialize_babelfish() in any upgrade script, they are falsely being considered as internal/system-generated object and initial_privileges are being stored for them which can cause inconsistency between initial privileges of a newly spawned database server and upgraded database server.

To avoid this situation, we should not store initial privileges for GRANT/REVOKE execution during upgrade. For achieving this,

• Extension Changes:
  This commit implements pltsql_allow_storing_init_privs_hook hook for checking whether to store initial privileges for given object or not.

  There are 3 category of handling storage of initial privileges:

  1. SAVE_INIT_PRIVS : Check if it is objects created during CREATE extension and
     store initial privs for them. system, information_schema_tsql
     objects and pltsql language are the examples of it.

  2. DISCARD_INIT_PRIVS : If it is schema contained object within system created
     TSQL schema like master, msdb or tempdb OR user created schema,
     Do not store initial privileges for them.

  3. ERROR_INIT_PRIVS : The default case when above 2 conditions doesn't match then error
     out. To avoid error please classify it between above 2 conditions.

• Engine Changes:
  Reverts the temporary fix 3f20518 and f9e9557. Added pltsql_check_store_init_privs_flag_hook hook for checking whether to store initial privileges or not.

Extension PR : babelfish-for-postgresql/babelfish_extensions#3136

Issues Resolved

BABEL-5410

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 PostgreSQL license, 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.

[rishabhtanwar29]

I think we should directly check the GUC here instead of doing it in a hook. We can put the required checks in guc_assign_hook if needed.

[HarshLunagariya]

1. I was going to do the same earlier, but this will be cleaner to manage. Because there will be condition needed whether we are in creation/alter phase or not / then what is the value of guc / then skip if superuser.
2. No, we can't really put those checks only in guc_assign_hook because we also want to make sure that it is being utilised only while creation and alter.