247-247: LGTM!

The function declaration follows the established pattern of other dump functions in the codebase.

10517-10519: LGTM!

The DO_PACKAGE case follows the established pattern for handling different object types.

18745-18745: LGTM!

The DO_PACKAGE case is correctly placed in the switch statement.

285-285: LGTM: Token and type declarations are well-structured

The new package-related tokens and semantic types are properly integrated into the grammar, following the existing patterns and conventions.

Also applies to: 727-727, 780-780, 797-797, 870-870

9977-9993: Verify package name validation and sharing clause implementation

A few points to verify:

1. Ensure package names are validated against SQL identifier rules
2. The opt_ora_sharing_clause usage needs implementation verification

#!/bin/bash
# Search for opt_ora_sharing_clause definition and usage
rg "opt_ora_sharing_clause" -A 5

#!/bin/bash
# Search for package name related rules and validation
rg "package_names" -A 5 src/backend/oracle_parser/ora_gram.y

# Search for any SQL identifier validation rules
ast-grep --pattern 'ColId:
  $$$'

#!/bin/bash
# Search for ora_func_name definition and usage since package_names uses it
rg "ora_func_name" src/backend/oracle_parser/ora_gram.y -A 5

#!/bin/bash
# Search for type_function_name definition and ColId usage
rg "type_function_name|ColId" src/backend/oracle_parser/ora_gram.y -A 5

23-23: Verify the existence of parse_package.c

The addition follows the build system conventions. Let's verify that the source file exists and contains the expected package parsing implementation.

#!/bin/bash
# Description: Verify the existence and basic structure of parse_package.c

# Check if the file exists and contains expected package-related functions
fd parse_package.c -t f | xargs grep -l "package"

# Look for basic package parsing functions that should be present
ast-grep --pattern 'static Node *parse_package_$_'

#!/bin/bash
# Check if parse_package.c exists and examine its content
fd parse_package.c -t f | xargs cat

# Look for package-related function declarations
ast-grep --pattern 'static Node *parse_package_$_'

# Look for package-related function declarations with different pattern
ast-grep --pattern 'Node *parse_package_$_'

#!/bin/bash
# Check if parse_package.c exists and examine its basic structure
fd parse_package.c -t f | xargs head -n 20

# Look for package-related function declarations with a different pattern
ast-grep --pattern 'static PkgType *parse_package_type'

# Look for package-related function declarations with another pattern
ast-grep --pattern 'static PkgVar *parse_package_var'

#!/bin/bash
# Look for package-related function declarations with a more specific pattern
rg -A 5 "parse_package\.[ch]" --type c

# Check for package-related header file
fd parse_package.h -t f | xargs cat

31-31: Include statement is appropriate

The inclusion of "utils/packagecache.h" is necessary for the new functionality and is correctly placed.

32-33: Ensure proper catalog annotations for 'pkgoid' field

The pkgoid field should have proper annotations to ensure correct catalog behavior. Verify that BKI_LOOKUP and other annotations are appropriate.

Please confirm that BKI_LOOKUP(pg_package) is correctly used and that pkgoid references the correct catalog.

49-52: Consistency in index naming and definitions

Ensure that index names and definitions follow the naming conventions and are consistent with existing catalog indexes.

Please verify that:

• The index names pg_package_body_oid_index and pg_package_body_pkgoid_index are unique and follow the project's naming conventions.
• The index definitions correctly reference the appropriate columns and use the correct operators.

54-55: Validate syscache definitions and number of attributes

Confirm that the MAKE_SYSCACHE macros have the correct number of attributes specified.

Ensure that the '8' in:

MAKE_SYSCACHE(PKGBODYOID, pg_package_body_oid_index, 8);
MAKE_SYSCACHE(PKGBODYPKGOID, pg_package_body_pkgoid_index, 8);

is the correct number of attributes for the syscache entries.

42-42: Check default value for 'pkgacl' field

Ensure that the default value for the pkgacl field is correctly set, and consider whether an explicit default is necessary.

Please confirm that:

• The default value _null_ is appropriate for pkgacl.
• If pkgacl should inherit default permissions, ensure that the default is set accordingly.

57-60: Consistency in index naming and definitions

Verify that the index names and definitions conform to naming conventions and correctly reference the columns.

Please check:

• Index names pg_package_oid_index and pg_package_pkgname_nsp_index for uniqueness and adherence to naming standards.
• Correct usage of operator classes in the index definitions.

62-63: Validate syscache definitions and number of attributes

Confirm that the MAKE_SYSCACHE macros have the correct parameters and attribute counts.

Ensure that:

• The syscache entries PKGOID and PKGNAMEARGSNSP are correctly defined.
• The attribute count (the '8' in the macros) is accurate.

28-35: Ensure proper memory management for pointers in structures

In PkgType struct, ensure that pointers like item and value are properly managed to prevent memory leaks or dangling pointers.

Please confirm that:

• The item pointer to PackageCacheItem and value pointer are correctly allocated and freed.
• Appropriate reference counting or memory context management is in place.

58-79: Verify function declarations and parameter consistency

Ensure that the function declarations match their implementations and that parameter names and types are consistent.

Please check:

• The correctness of function signatures for LookupPkgTypeByTypename, LookupPkgVarByvarnames, LookupPkgEntryByTypename, and LookupPkgFunc.
• That LookupPkgFunc parameters align with existing conventions in similar parser functions.

36-50: Ensure correctness in status flag definitions and macros

Confirm that the status flags and associated macros for PackageCacheStatus are correctly defined and used.

Please verify:

• The bitwise operations in the macros are correct.
• The flags do not conflict and are appropriately distinct.

61-70: Verify memory management in 'PackageCacheItem' struct

Ensure that the ctxt memory context and source pointer are properly managed to prevent memory leaks.

Please confirm:

• That ctxt is appropriately allocated and freed.
• That source data is managed within the ctxt memory context.

90-106: Ensure function prototypes match implementations

Verify that the function declarations match the definitions in the implementation files.

Please check:

• Parameter types and return types are consistent.
• Functions like ValidatroPackage (possible typo) should be correctly named, perhaps ValidatorPackage.

28-28: Include 'utils/dsa.h' for DSA functions

The inclusion of #include "utils/dsa.h" is appropriate for using DSA functions.

Line range hint 103-107: Ensure proper detachment and cleanup in 'DetachSession'

Confirm that all resources are properly released in DetachSession.

Please verify that:

• The dsa_detach is called after dsm_detach.
• Any additional cleanup required for the session is performed.

166-174: ⚠️ Potential issue

Check for Null item After PackageHandle Call

The PackageHandle function may return NULL, but the code does not check for this before using item, potentially leading to a null pointer dereference.

Add a null check after calling PackageHandle:

     if (PackageCacheIsValid(pkey, false))
         item = PackageCacheLookup(pkey);
     else
         item = PackageHandle(*pkey, false);

+    if (item == NULL)
+        return NULL;

Likely invalid or redundant comment.

75-80: ⚠️ Potential issue

Handle Unexpected List Sizes in Switch Statement

The switch statement on list_size does not handle cases where list_size is greater than 3. This could lead to unexpected behavior for larger lists.

Modify the switch statement to handle all possible cases or add a default case:

     switch (list_size)
     {
         case 0:
         case 1:
             /* doesn't support reference a package type exclude pkg name */
             return false;
+        default:
+            /* Handle cases where list_size > 3 appropriately */
+            break;
     }

Likely invalid or redundant comment.

123-124: ⚠️ Potential issue

Add Null Check Before String Comparison

In package_resolve_names, first_name is used without checking if it's NULL, which could lead to a crash if list_length(names) is less than expected.

Add a null check for first_name:

+    if (first_name == NULL)
+        return false;

     if (strcmp(first_name, get_database_name(MyDatabaseId)) == 0)

Likely invalid or redundant comment.

82-110: ⚠️ Potential issue

Missing Resource Release in PackageCacheIsValid

The function PackageCacheIsValid may return early without releasing the cache tuple if tuple is not valid, leading to a resource leak.

Ensure that ReleaseSysCache(tuple); is called before any return statement after SearchSysCache1:

     if (!HeapTupleIsValid(tuple))
+    {
+        ReleaseSysCache(tuple);
         return false;
+    }

Likely invalid or redundant comment.

238-246: Impact of Unconditional Package Type Lookup

Introducing LookupPkgTypeByTypename unconditionally in LookupTypeNameOid might affect the behavior of type lookups, especially if package types are not intended to be used in all contexts.

Please verify that this change does not adversely affect existing type lookup logic when package types are not involved.

Line range hint 659-783: Comprehensive Dependency Handling When Altering Package Schema

When changing the schema of a package in ExecAlterObjectSchemaStmt and AlterObjectNamespace_internal, all dependencies and references to the package need to be updated accordingly.

Ensure that altering a package's schema updates all dependencies, and that no orphaned references remain.

704-706: Ensure Correct Token Length Calculation for PACKAGE

The cur_token_length for the PACKAGE token is set to 7. Verify that this length calculation accurately reflects the token length, especially if there are any changes to the token definitions elsewhere.

779-784: Handle PACKAGE BODY Token Appropriately

The logic replaces PACKAGE with PACKAGE_BODY when followed by BODY. Ensure that the PACKAGE_BODY token is correctly defined and handled in all relevant parts of the parser and that this change does not affect existing functionality related to the PACKAGE token.

359-368: Check for Proper Handling of New Catalog Attributes

The new attributes protypenames and rettypename are being set based on parametertypeNames and rettypeName. Verify that these attributes are correctly defined in the system catalog and that they interact properly with existing attributes.

870-872: ⚠️ Potential issue

Null Pointer Check for tuple

Ensure that tuple is checked for NULL before dereferencing it. Although you have an error check, it's important to handle the possibility of a NULL return from SearchSysCache1 to prevent potential null pointer dereferences.

Apply this diff to add a null check:

 if (!HeapTupleIsValid(tuple))
     ereport(ERROR,
             (errcode(ERRCODE_UNDEFINED_OBJECT),
              errmsg("package body with OID %u does not exist", bodyid)));

+ if (tuple == NULL)
+     elog(ERROR, "Failed to find package body with OID %u", bodyid);

 pkgOid = ((Form_pg_package_body) GETSTRUCT(tuple))->pkgoid;

Likely invalid or redundant comment.

1476-1478: Verify Usage of repl_func_real_argtype

The function repl_func_real_argtype is called to possibly replace argument types from a package. Ensure that this function handles all necessary cases and that it correctly modifies *p_argtypes as intended.

1863-1907: ⚠️ Potential issue

Missing Null Checks in get_func_typename_info

In the function get_func_typename_info, there are potential missing null checks after SysCacheGetAttr calls. If these calls return NULL, accessing the results could lead to null pointer dereferences. Ensure that p_argtypeNames and rettypeName are only used when not NULL.

Apply this diff to add null checks:

if (p_argtypeNames != NULL)
{
    protypenames = SysCacheGetAttr(PROCOID, procTup,
                                   Anum_pg_proc_protypenames,
                                   &isNull);
    if (!isNull)
    {
        // Existing code to process protypenames
    }
+   else
+   {
+       *p_argtypeNames = NULL;
+   }
}

if (rettypeName != NULL)
{
    prorettypename = SysCacheGetAttr(PROCOID, procTup,
                                     Anum_pg_proc_rettypename,
                                     &isNull);
    if (!isNull)
    {
        *rettypeName = TextDatumGetCString(prorettypename);
    }
+   else
+   {
+       *rettypeName = NULL;
+   }
}

Likely invalid or redundant comment.

1749-1761: Add new function setPlanCacheInvalidForPackage to invalidate plans referencing a package

This new function computes a hash value for the given package OID and calls PlanCacheObjectCallback to invalidate any plans that depend on that package. This is important to ensure cached plans are refreshed when a package is modified.

1763-1771: Add new callback PlanCachePackageBodyCallback to invalidate plans on package body changes

This callback is registered to handle invalidation when a package body is modified. Since the hash value cannot be matched in this case, it calls PlanCacheObjectCallback with a hash value of 0 to invalidate all plans referencing the package. This comprehensive invalidation is necessary since the specific changes in the package body are unknown.

743-744: Add new macros to identify function types related to packages

The new macros FUNC_FROM_PACKAGE and FUNC_FROM_PACKGE_INITBODY allow identifying functions originating from packages. This is important metadata to track the source of functions.

747-752: Update FUNC_EXPR_FROM_PG_PROC macro to handle new package function types

The macro is updated to return false for the new package function types FUNC_FROM_PACKAGE and FUNC_FROM_PACKGE_INITBODY. This ensures the macro correctly differentiates between regular and package functions.

785-787: Add new fields to FuncExpr structure for package-related metadata

The FuncExpr structure is extended with fields function_name, ref_pkgtype, and pkgoid to store the package-related metadata such as the function name used in a package, whether it references a package type, and the package's OID. This allows tracking important information for package functions.

92-93: Add rettypename parameter to compute_return_type function

The function signature is updated to return the name of the return type via the new rettypename output parameter. This allows capturing the return type name for package functions.

100-128: Look up return type from package for PL/SQL functions

For PL/SQL functions, the code first attempts to look up the return type from a package using LookupPkgTypeByTypename. If a package type is found, it updates the return type details accordingly, including prepending the package schema name if needed. This ensures package return types are correctly resolved.

230-231: Add parametertypeNames parameter to interpret_function_parameter_list

The function signature is extended with the parametertypeNames output parameter to collect the names of the parameter types. This is used for package function parameters.

258-266: Allocate array for parameter type names for PL/SQL functions

For PL/SQL functions, an array typeNames is allocated to store the parameter type names. This is necessary to handle package types used as function parameters.

285-351: Look up parameter types from packages for PL/SQL functions

Similar to the return type handling, the code attempts to resolve parameter types from packages for PL/SQL functions. If a package type is found, it updates the parameter type details and stores the type names. Appropriate error handling is added for undefined types.

567-583: Build array of parameter type names for package types

If any package types were found in the function parameters, the code builds an array parametertypeNames containing their names. This array is returned to the caller to provide information about package type parameters.

285-301: Look up functions in packages if regular lookup fails

If the initial function lookup fails and the function name is a single identifier, the code attempts to look it up as a package function by prepending a "standard" prefix to the name. If a package function is found, the pkgoid is set in the FuncExpr node. This allows resolving functions defined in packages.

303-315: Perform package function lookup if subproc hook lookup fails

If the subproc hook lookup fails to find the function, the code falls back to a package function lookup using LookupPkgFunc. If successful, the function is marked as originating from a package. This provides a secondary lookup mechanism for package functions.

812-847: Set package-related fields in FuncExpr node

The pkgoid field is set to the resolved package OID. If the function is from a package, additional fields like function_name are populated based on the package details. For regular functions, a check is added to see if any argument or return types come from a package, in which case ref_pkgtype is set to true. This metadata is important for tracking package dependencies and origins of types.

68-70: Ensure proper ordering and necessity of new header files

The inclusion of pg_package.h, pg_package_body.h, and packagecmds.h adds necessary definitions for package management support. Verify that these headers are required and that their inclusion follows the project's convention for header file ordering and grouping.

150-198: Update object_classes array with new package-related entries

The object_classes array now includes PackageRelationId and PackageBodyRelationId, which map OCLASS_PACKAGE and OCLASS_PACKAGE_BODY to their respective catalog OIDs. This update is essential for managing dependencies involving packages and their bodies.

90-91: Confirm the necessity of including packagecache.h

The addition of #include "utils/packagecache.h" suggests that the file utilizes caching mechanisms for packages. Ensure that functions or definitions from packagecache.h are indeed used in this file. If not, consider removing this inclusion to avoid unnecessary dependencies.

Run the following script to check for usages of packagecache.h:

1445-1452: ⚠️ Potential issue

Handle deletion of package and package body objects

In the doDeletion function, cases for PackageRelationId and PackageBodyRelationId have been added to handle the deletion of packages and package bodies by invoking DropPackageById and DropPackageBodyById respectively.

Ensure that DropPackageById and DropPackageBodyById properly handle all necessary checks, such as permission verification and dependency management. Additionally, confirm that these functions correctly release any allocated resources to prevent memory leaks or dangling pointers.

Run the following script to verify the implementations:

#!/bin/bash
# Description: Check if `DropPackageById` and `DropPackageBodyById` handle permissions and dependencies

# Search for the definitions and check for permission and dependency handling
ast-grep --pattern $'void DropPackageById(Oid packageId) {
  $$$
  /* Expected: Check permissions */
  /* Expected: Manage dependencies */
  $$$
}' src/backend/commands/packagecmds.c

ast-grep --pattern $'void DropPackageBodyById(Oid packageBodyId) {
  $$$
  /* Expected: Check permissions */
  /* Expected: Manage dependencies */
  $$$
}' src/backend/commands/packagecmds.c

#!/bin/bash
# Let's try a different approach to find these functions and their implementations

# First, let's check if the file exists
fd "packagecmds.c" --type f

# Then, let's use ripgrep to find the function definitions with context
rg "DropPackageById|DropPackageBodyById" -A 20

# Also search for any related permission checks
rg "aclcheck|ACL_|ACLCHECK_" --type c

# And search for memory management related calls
rg "pfree|palloc|MemoryContext" -A 2 --type c

#!/bin/bash
# Let's search for the implementation details of these functions
# and their dependencies

# Search for package-related functions
rg "DropPackage|FreePackageCache" -A 5 --type c

# Search for package-related permission checks
rg "pg_package_aclcheck" -A 5 --type c

# Search for package-related memory management
rg "package.*cache" -A 5 --type c

# Search for package-related dependency management
rg "recordDependencyOn.*Package" -A 5 --type c

59-59: Include packagecmds.h for package command support

The inclusion of "commands/packagecmds.h" is necessary to provide declarations for package-related command functions. Ensure that this header is included in the correct order according to the project's coding standards.

179-181: Classify package commands as non-read-only

The ClassifyUtilityCommandAsReadOnly function now includes cases for T_CreatePackageStmt, T_CreatePackageBodyStmt, and T_AlterPackageStmt. This correctly classifies package-related commands as not read-only, which is essential for the database's consistency and security.

1922-1931: Add handling for package commands in ProcessUtilitySlow

Package commands are now properly handled in the ProcessUtilitySlow function, with cases added for:

• T_CreatePackageStmt calling CreatePackage
• T_CreatePackageBodyStmt calling CreatePackageBody
• T_AlterPackageStmt calling AlterPackage

2360-2362: Add command tag for ALTER PACKAGE operation

In the AlterObjectTypeCommandTag function, a new case for OBJECT_PACKAGE has been added, mapping to CMDTAG_ALTER_PACKAGE. This ensures that ALTER PACKAGE commands are correctly tagged and logged.

2671-2676: Include command tags for dropping packages

The CreateCommandTag function now includes cases for OBJECT_PACKAGE and OBJECT_PACKAGE_BODY, mapping to CMDTAG_DROP_PACKAGE and CMDTAG_DROP_PACKAGE_BODY respectively. This addition ensures that drop operations for packages are correctly identified and handled.

3263-3272: Add command tags for package creation and alteration

The CreateCommandTag function has been updated to include:

• T_CreatePackageStmt mapping to CMDTAG_CREATE_PACKAGE
• T_CreatePackageBodyStmt mapping to CMDTAG_CREATE_PACKAGE_BODY
• T_AlterPackageStmt mapping to CMDTAG_ALTER_PACKAGE

This ensures that package-related commands are properly tagged for logging and processing.

3807-3812: Set appropriate log levels for package commands

In GetCommandLogLevel, the package commands are assigned a log level of LOGSTMT_DDL. This is appropriate as these commands are data definition language operations and should be logged accordingly.

2970-2972: Handle DISCARD PACKAGES in DiscardStmt

A new case DISCARD_PACKAGES has been added to the DiscardStmt handling. This allows the DISCARD command to properly handle the cleanup of package-related resources.

Run the following script to verify that DiscardCommand correctly handles DISCARD_PACKAGES:

53-54: Include necessary headers for package support

The inclusion of "funcapi.h" and "parser/parse_package.h" provides necessary function APIs and package parsing capabilities. Ensure these headers are required and included according to the project's header inclusion guidelines.

1668-1673: Modify get_func_rettype to use get_func_real_rettype

The get_func_rettype function now calls get_func_real_rettype to obtain the actual return type, especially when dealing with package variables in Oracle compatibility mode. This change ensures that the function's return type is accurate in different compatibility settings.

Line range hint 1868-1913: Update get_func_signature to reflect real return and argument types

In get_func_signature, the function now retrieves the real return type using get_func_real_rettype and updates the argument types with repl_func_real_argtype. This change ensures that the function signature is accurate, especially when types are affected by package variables in Oracle compatibility mode.

Line range hint 1914-1931: Verify proper handling of function variadic types and return sets

Ensure that get_func_variadictype and get_func_retset correctly handle functions with variadic arguments and those that return sets, respectively. Changes in the function type retrieval may affect these behaviors.

Run the following script to test functions with variadic arguments and return sets:

#!/bin/bash
# Description: Verify handling of variadic functions and functions returning sets

# Test functions with variadic arguments
ast-grep --pattern $'Oid get_func_variadictype(Oid funcid) {
  $$$
}' src/backend/utils/cache/lsyscache.c

# Test functions that return sets
ast-grep --pattern $'bool get_func_retset(Oid funcid) {
  $$$
}' src/backend/utils/cache/lsyscache.c

1708-1867: 🛠️ Refactor suggestion

⚠️ Potential issue

Implement repl_func_real_argtype to replace function argument types

The function repl_func_real_argtype updates the argument types of a function to their actual types, considering package variables in Oracle compatibility mode. This ensures that the function signature accurately reflects any dynamic types influenced by packages.

There is a potential for buffer overruns in the loops starting at line 1766 and line 1841. Ensure that array bounds are checked when accessing p_argtypeNames and other arrays to prevent reading beyond their allocated memory.

Add checks to validate array indices before accessing array elements.

for (i = 0; i < numargs; i++)
{
+   if (i >= numargs) // Ensure we are within bounds
+       break;

    /* existing code */
}

Likely invalid or redundant comment.

44-45: Include necessary headers for package management

The addition of #include "catalog/pg_package.h" and #include "commands/packagecmds.h" is appropriate to support package management functionalities.

52-52: Include parser header for package parsing

Including parse_package.h is necessary for parsing package-related SQL commands.

5094-5104: Ensure consistency with pg_*_is_visible functions

The implementation of pg_package_is_visible is consistent with other pg_*_is_visible functions, correctly checking the existence of the package and returning the visibility status.

1790-1793: Ensure updated function calls match new signature

The function call to ProcedureCreate in makeRangeConstructors includes the new parameters as per the updated function signature. This ensures compatibility and correctness.

2317-2318: Addition of OBJECT_PACKAGE and OBJECT_PACKAGE_BODY to ObjectType enum.

The addition of OBJECT_PACKAGE and OBJECT_PACKAGE_BODY to the ObjectType enumeration expands the supported object types, enabling package-related functionalities.

2303-2303: ⚠️ Potential issue

Verify the use of NameStr with pg_package_tuple->pkgname.

Ensure that pg_package_tuple->pkgname is of type NameData before using NameStr macro. If pkgname is not NameData, accessing it with NameStr may lead to incorrect behavior.

Apply this diff to correct the usage if necessary:

-    									 NameStr(pg_package_tuple->pkgname),
+    									 TextDatumGetCString(pg_package_tuple->pkgname),

Run the following script to check the data type of pkgname in pg_package:

#!/bin/bash
# Description: Verify the data type of pkgname in pg_package.

# Search for the definition of Form_pg_package
rg -A 5 'typedef struct FormData_pg_package' src/include/catalog/pg_package.h

# Check the declaration of pkgname
rg 'pg_catalog\.name\s+pkgname' src/include/catalog/pg_package.h

#!/bin/bash
# Let's try a different approach to find the structure definition and type of pkgname

# Search for pkgname in pg_package.h with more context
rg -A 10 'pg_package' src/include/catalog/pg_package.h

# Also check for NameData type definition which is commonly used with NameStr
rg 'typedef.*NameData' src/include/c.h

# Look for the actual usage context of pg_package_tuple
rg -B 2 -A 2 'pg_package_tuple.*pkgname' src/backend/catalog/

2323-2327: Ensure proper zero-initialization of arrays before use.

The arrays values, nulls, and replaces are stack-allocated but may not be zero-initialized in all contexts. Confirm that MemSet or memset correctly initializes the entire arrays.

Run the following script to ensure MemSet is correctly used for array initialization:

MemSet(values, 0, sizeof(values));
MemSet(nulls, false, sizeof(nulls));
MemSet(replaces, false, sizeof(replaces));

#!/bin/bash
# Description: Check for proper usage of MemSet or memset for array initialization.

# Search for MemSet and memset usage in the codebase
rg 'MemSet\((\w+),\s*(0|false),\s*sizeof\(\1\)\)' src/
rg 'memset\((\w+),\s*(0|false),\s*sizeof\(\1\)\)' src/

#!/bin/bash
# Description: Check for proper usage of MemSet or memset for array initialization
# Using simpler pattern matching without backreferences

# Search for array initialization context around the specific line
rg -B 10 -A 10 "MemSet\(replaces, false, sizeof\(replaces\)\)" src/backend/catalog/aclchk.c

# Look for declarations and initializations of values and nulls arrays
rg -B 5 -A 5 "bool\s+replaces\[|Datum\s+values\[|bool\s+nulls\[" src/backend/catalog/aclchk.c

642-669: Add handling for new object types OBJECT_PACKAGE and OBJECT_PACKAGE_BODY.

The changes add new entries to the ObjectProperty array for the OBJECT_PACKAGE and OBJECT_PACKAGE_BODY object types. This allows the get_object_address() function to handle these new types when looking up object addresses.

2607-2619: Add ownership checks for OBJECT_PACKAGE and OBJECT_PACKAGE_BODY.

The check_object_ownership() function is updated to handle the new OBJECT_PACKAGE and OBJECT_PACKAGE_BODY types. It calls the appropriate ownership check functions pg_package_ownercheck() and pg_packagebody_ownercheck() for these types.

4081-4107: Add cases to handle OBJECT_PACKAGE and OBJECT_PACKAGE_BODY in getObjectDescription().

The getObjectDescription() function is extended to handle the new object types. For OBJECT_PACKAGE, it retrieves the package name and schema using get_package_nameinfo(). For OBJECT_PACKAGE_BODY, it uses get_package_nameinfo_bybodyid() to get the package name and schema based on the package body OID.

5995-6025: Add cases to handle OBJECT_PACKAGE and OBJECT_PACKAGE_BODY in getObjectIdentityParts().

Similar to the changes in getObjectDescription(), the getObjectIdentityParts() function is updated to handle the new object types. It retrieves the package name and schema for OBJECT_PACKAGE and OBJECT_PACKAGE_BODY using the respective helper functions.

2612-2616: Set package type information for function expressions.

In the simplify_function() function, a new check is added for function expressions that come from a package. If the ref_pkgtype flag is set, the set_pkgtype_from_funcexpr() function is called to set the package type information for the function expression.

2630-2632: Set package information for function expressions.

Another check is added in simplify_function() to set the package information for function expressions that come from a package. The set_pkginfo_from_funcexpr() function is called to populate the package-related fields in the FuncExpr node.

4387-4396: Replace function argument types with real types for package functions.

In the expand_function_arguments() function, a new block of code is added specifically for the Oracle compatibility mode. It creates a copy of the proargtypes array and calls repl_func_real_argtype() to replace the argument types with the real types for functions that belong to a package.

4584-4586: Get the real return type of a function.

The get_func_real_rettype() function is used to retrieve the real return type of a function from its pg_proc tuple. This ensures that the correct return type is used for functions that belong to a package.

5362-5363: Get the real return type of a function.

Similar to the previous change, the get_func_real_rettype() function is used to get the real return type of a function when checking if it returns RECORD in the inline_set_returning_function() function.

3429-3526: Verify error handling for invalid package OID.

The function looks up the pg_package tuple using the given package OID. It throws an error if the tuple is not found. This error handling looks appropriate.

3462-3464: Verify the DEFAULT COLLATION clause generation.

The DEFAULT COLLATION clause is generated if pkg_form->use_collation is true. The hardcoded collation name "USING_NLS_COMP" is used. Ensure this is the correct behavior and consider making the collation name configurable if needed.

18-18: LGTM! Verify related cache implementation files.

The addition of packagecache.c to backend sources is consistent with the caching infrastructure.

Let's verify the existence and structure of related cache implementation files:

#!/bin/bash
# Description: Verify the existence and basic structure of package cache files

# Check if the implementation file exists
fd -t f "packagecache.c" src/backend/utils/cache/

# Check if the header file exists
fd -t f "packagecache.h" src/include/utils/

# Verify basic structure of cache implementation
rg -A 5 "struct\s+PackageCache|PackageCacheLookup|PackageCacheInsert" 

29-30: LGTM! Object file addition is consistent.

The addition of packagecache.o to OBJS aligns with the source file addition in meson.build.

53-53: LGTM! Verify package command implementation.

The addition of packagecmds.c to backend sources is consistent with the command handling infrastructure.

Let's verify the package command implementation:

#!/bin/bash
# Description: Verify package command implementation structure

# Check if the implementation file exists
fd -t f "packagecmds.c" src/backend/commands/

# Verify command handler registration
rg -A 5 "CreatePackageStmt|AlterPackageStmt|DropPackageStmt" 

# Check for package-related GUC parameters
rg "package" src/backend/utils/misc/guc.c

#!/bin/bash
# Let's verify the implementation details of the package commands

# Check the actual implementation of package commands
ast-grep --pattern 'CreatePackage($$$) {
  $$$
}'

# Check for package-related error messages and catalog definitions
rg "ERROR.*package" src/
rg "CATALOG.*package" src/

# Check for package-related test files
fd -t f "package.*test" -e "sql"

25-27: Verify transaction and permission handling in package operations

The create/alter operations and ownership checks should be properly integrated with PostgreSQL's transaction and permission systems.

Also applies to: 31-32

#!/bin/bash
# Search for transaction and permission handling patterns
rg -A 3 "BeginInternalSubTransaction|CommitTransactionCommand|AbortCurrentTransaction" src/backend/commands/packagecmds.c

# Check for proper ACL checks
rg -A 3 "aclcheck|pg_namespace_aclcheck" src/backend/commands/packagecmds.c

#!/bin/bash
# Search for transaction handling in internal functions
ast-grep --pattern 'ObjectAddress CreatePackage_internal($$$)' src/backend/commands/packagecmds.c

# Look for other transaction-related functions
rg "StartTransactionCommand|CommitTransactionCommand|BeginTransactionBlock|EndTransactionBlock" src/backend/commands/packagecmds.c

# Check if these commands are wrapped in a transaction block
rg -B 2 -A 5 "CreatePackage_internal|CreatePackageBody_internal|AlterPackage_internal" src/backend/commands/packagecmds.c

#!/bin/bash
# Check if these operations are properly integrated with standard command processing
rg -B 2 -A 5 "ProcessUtility.*package" src/backend/tcop/

# Look for standard transaction handling patterns in the utility command processing
rg "CommandCounterIncrement|RegisterCreatedObjectsInNamespaces" src/backend/commands/packagecmds.c

# Check for proper object dependency handling
rg "recordDependencyOn|recordDependencyOnOwner" src/backend/commands/packagecmds.c

64-65: LGTM: Proper integration of package commands

The addition of packagecmds.o follows the established pattern and maintains alphabetical ordering.

24-24: LGTM: Include statement properly placed

The include statement for packagecache.h is correctly placed in the utils includes section.

49-52: LGTM: DISCARD PACKAGES implementation

The implementation follows the established pattern for DISCARD commands and correctly handles package cache reset.

84-84: LGTM: Package cache reset in DiscardAll

ResetPackageCaches() is appropriately added to DiscardAll alongside other cache resets.

36-36: LGTM: New type name formatting function

The TypeNameToQuoteString function declaration follows the established pattern and is properly placed alongside related functions.

39-40: LGTM! Package-related enum values are properly integrated.

The addition of OraBody_PACKAGE and OraBody_PACKAGEBODY to OraBodyStyle enum is well-placed and consistent with the existing structure. These values are essential for distinguishing between package declarations and their implementations.

37-39: LGTM! Package description function follows established patterns.

The describePackages function declaration maintains consistency with other describe functions in terms of:

• Parameter types and names
• Return type
• Documentation style
• Function naming convention

72-73: Verify catalog header ordering dependencies.

While the addition of pg_package.h and pg_package_body.h appears correct, the file comment indicates there are ordering dependencies for catalog headers. Please verify that:

1. These new catalogs don't need to appear before any existing ones
2. There are no dependencies between pg_package.h and pg_package_body.h that would require a specific order

#!/bin/bash
# Description: Check for potential ordering dependencies in catalog headers

# Search for references to pg_package in other catalog headers
echo "Checking for references to pg_package in other catalog headers:"
rg -l "pg_package" --type cpp

# Look for BKI_BOOTSTRAP or similar markers in the new catalog headers
echo "Checking for BKI_BOOTSTRAP markers:"
rg "BKI_BOOTSTRAP" pg_package.h pg_package_body.h

# Check for foreign key relationships
echo "Checking for foreign key relationships:"
rg "FOREIGN_KEY" pg_package.h pg_package_body.h

#!/bin/bash
# Let's check the actual catalog header files in their correct location
echo "Checking catalog headers content:"
cat src/include/catalog/pg_package.h src/include/catalog/pg_package_body.h

# Check for any ordering comments in the catalog directory
echo -e "\nChecking for ordering comments in catalog directory:"
rg -i "order" src/include/catalog/

# Check for dependencies between package and package_body
echo -e "\nChecking for dependencies between package and package_body:"
rg "package" src/include/catalog/pg_package.h src/include/catalog/pg_package_body.h

# Check for any foreign key or bootstrap declarations
echo -e "\nChecking for foreign keys and bootstrap declarations:"
rg -e "FOREIGN" -e "BKI_" src/include/catalog/pg_package.h src/include/catalog/pg_package_body.h

84-86: Verify catalog header ordering dependencies

The placement of new catalog headers needs verification as the comment states that "BKI_BOOTSTRAP catalogs must appear first, and pg_statistic before pg_statistic_ext_data, and there are reputedly other, undocumented ordering dependencies."

#!/bin/bash
# Description: Check if any of the removed or added catalog headers have BKI_BOOTSTRAP
# or other ordering dependencies.

# Check for BKI_BOOTSTRAP in the new and removed files
echo "Checking for BKI_BOOTSTRAP and dependencies..."
rg "BKI_BOOTSTRAP" src/include/catalog/pg_package.h src/include/catalog/pg_package_body.h

# Check references to subscription_rel to understand impact of removal
echo "Checking references to subscription_rel..."
rg -l "subscription_rel" --type cpp

#!/bin/bash
# Check the Makefile and comments about catalog ordering
echo "Checking Makefile for catalog ordering comments..."
cat src/include/catalog/Makefile

# List all catalog headers to understand the full ordering context
echo -e "\nListing all catalog headers..."
fd "pg_.*\.h$" src/include/catalog/

# Check if pg_package or pg_package_body are referenced by other catalogs
echo -e "\nChecking references to new package catalogs..."
rg "pg_package" --type cpp

114-117: Clarify NOT NULL constraint implementation

The comment states these fields are "NOT NULL for package types", but they use BKI_DEFAULT(_null_). This seems contradictory. Consider:

1. Adding explicit validation in the code
2. Documenting how this constraint is enforced
3. Adding a check constraint in the catalog

#!/bin/bash
# Description: Check how NOT NULL constraints are implemented for package types

# Look for validation code
echo "Checking for validation implementation..."
rg "rettypename|protypenames" --type cpp

# Look for similar patterns in other catalog definitions
echo "Checking for similar patterns in other catalogs..."
rg "NOT NULL.*BKI_DEFAULT\(_null_\)" src/include/catalog/

#!/bin/bash
# Let's check for package type validation patterns and related code

# Look for package type validation code
echo "Searching for package type validation..."
rg "package.*type" -B2 -A2 --type cpp

# Check for validation in ProcedureCreate
echo "Checking ProcedureCreate implementation..."
ast-grep --pattern 'ProcedureCreate($$$)'

# Look for NOT NULL constraint implementations in catalog code
echo "Checking catalog constraint patterns..."
rg "check.*constraint|validate.*constraint" --type cpp src/backend/catalog/

# Search for package type related functions
echo "Searching for package type related functions..."
rg "package.*type|is_package" --type cpp

#!/bin/bash
# Let's check for package type validation in PL/SQL package code

# Look for package type validation in pl_package files
echo "Searching for package type validation in pl_package..."
rg "package.*type.*validation|package.*type.*null" src/pl/plisql/src/pl_package.*

# Check for type validation in package-related code
echo "Checking package type validation in catalog code..."
rg "package.*type.*check|package.*type.*validate" src/backend/catalog/

# Look for package type constraint handling
echo "Searching for package type constraint handling..."
ast-grep --pattern 'if ($_ && $_->package_type) {
  $$$
}'

#!/bin/bash
# Let's check how package types are handled in the codebase

# Look for package type handling in procedure creation/modification code
echo "Checking package type handling in procedure code..."
rg "package.*type|rettypename|protypenames" src/backend/commands/

# Search for package type validation in type-related code
echo "Searching type validation code..."
rg "typname|type.*validate|type.*check" src/backend/catalog/pg_type*

# Look for BKI_DEFAULT handling
echo "Checking BKI_DEFAULT handling..."
rg "BKI_DEFAULT.*_null_" src/include/catalog/

28-29: LGTM! Include directive properly placed.

The addition of lsyscache.h is appropriate for accessing get_func_real_rettype.

168-169: LGTM! Improved return type validation.

The change to use get_func_real_rettype enhances type checking by considering the actual return type instead of just the declared type.

19-20: LGTM! Include directive properly placed.

The addition of array.h is necessary for the ArrayType return type used in the new functions.

128-130: LGTM! Well-structured function declarations.

The new functions for handling real types are properly placed and follow consistent naming patterns. They enhance PostgreSQL's type system capabilities, particularly important for package support.

Let's verify the usage of these new functions:

#!/bin/bash
# Check for function usage across the codebase
rg "get_func_real_rettype|repl_func_real_argtype|get_func_real_allargtype" -A 2

173-173: Verify package function return type resolution

The change to use get_func_real_rettype() is appropriate for better return type resolution, especially in the context of package functions. However, we should verify that this function correctly handles package function return types.

#!/bin/bash
# Description: Check if get_func_real_rettype is properly implemented for package functions
# Test: Search for get_func_real_rettype implementation and its package-related logic

# Look for the implementation
rg -A 10 "get_func_real_rettype"

# Look for package-related return type handling
ast-grep --pattern 'get_func_real_rettype($_) {
  $$$
  if ($_ && $_->pkgoid) {
    $$$
  }
  $$$
}'

#!/bin/bash
# Look for package-related return type handling in get_func_real_rettype implementation
rg -A 20 "get_func_real_rettype\(HeapTuple proc_tup\)"

238-239: LGTM: New function declaration for package plan cache invalidation

The declaration of setPlanCacheInvalidForPackage follows proper conventions and integrates well with the existing plan cache infrastructure.

243-245: LGTM: Package ACL function declarations

The new ACL functions for packages follow the established patterns and integrate well with the existing ACL infrastructure.

160-161: LGTM: Enhanced type resolution for package functions.

The changes correctly handle type resolution for package functions by:

1. Replacing argument types with their real types
2. Updating the return type with its real type

This ensures proper type handling when functions are called via the fastpath interface.

304-305: LGTM: Improved return type validation for hash functions.

The change enhances type validation by using get_func_real_rettype to check the actual return type, which is essential for proper type resolution in the context of packages.

49-49: LGTM: Comprehensive command tag support for packages.

The added command tags properly support the complete lifecycle of packages:

• Creation: CREATE PACKAGE, CREATE PACKAGE BODY
• Modification: ALTER PACKAGE
• Cleanup: DISCARD PACKAGES
• Removal: DROP PACKAGE, DROP PACKAGE BODY

All tags maintain proper alphabetical ordering and have appropriate flags set:

• event_trigger_ok: true for DDL operations
• table_rewrite_ok: false as packages don't involve table rewrites

Also applies to: 105-106, 136-136, 161-162

300-301: LGTM: Variable declaration for parameter type names.

The addition of parametertypeNames aligns with the function signature changes to support package types.

95-96: LGTM: Consistent handling of security labels for package objects.

The addition of OBJECT_PACKAGE and OBJECT_PACKAGE_BODY to the list of objects that don't support security labels is appropriate and follows the established pattern.

337-351: LGTM: Well-structured implementation of package drop handling.

The implementation correctly:

1. Checks for schema existence
2. Provides distinct messages for packages and package bodies
3. Follows the established pattern for other object types

However, consider adding a verification step to ensure proper cleanup of package-related objects.

#!/bin/bash
# Description: Verify the cleanup of package-related objects
# Test: Search for package-related cleanup code in dependency handling

# Check for package dependency handling
ast-grep --pattern 'case OBJECT_PACKAGE:
  $$$
  break;'

# Check for package body dependency handling
ast-grep --pattern 'case OBJECT_PACKAGE_BODY:
  $$$
  break;'

#!/bin/bash
# Search for package-related dependency handling and cleanup code
rg -A 5 "RemovePackage|DropPackage|drop.*package" --type c

538-540: LGTM: Proper initialization of new package-related fields

The new fields are correctly initialized with safe default values:

• function_name set to NULL
• ref_pkgtype set to false
• pkgoid set to InvalidOid

401-401: LGTM: Package OID field added with size constraint maintained

The addition of pkgoid to track package variables is well-placed in the cparam struct. The change maintains the ExprEvalStep's size constraint of 64 bytes as verified by the existing StaticAssertDecl.

223-232: LGTM: Well-structured package information type

The PkgInfo struct follows the established pattern for objects with ACLs:

• Inherits from DumpableObject
• Includes owner information
• Contains ACL fields for both regular and initial privileges

751-751: LGTM: Consistent function prototype

The getPackages function declaration follows the established pattern of other catalog access functions in the file.

44-44: Verify package dump order dependencies

The placement of DO_PACKAGE between DO_EXTENSION and DO_FUNC in the DumpableObjectType enum affects the dump order. Please verify that packages are dumped after their dependencies (extensions) and before objects that might depend on them (functions).

#!/bin/bash
# Description: Check if there are any functions or other objects that reference packages
# This helps verify if the dump order is correct

# Search for references to packages in function definitions
rg -l "PACKAGE" | grep -i "function\|procedure"

# Search for direct dependencies on packages
ast-grep --pattern 'CREATE $_ FUNCTION $_ PACKAGE $_'

#!/bin/bash
# Check for package-related code in pg_dump implementation
rg -A 5 "DO_PACKAGE" src/bin/pg_dump/

# Look for dump order handling
rg -A 10 "sortDumpableObjects" src/bin/pg_dump/

# Check for package dependency handling
rg -A 5 "addDumpableDependency|getDumpableDependency" src/bin/pg_dump/

#!/bin/bash
# Check for package dependency handling in the implementation
rg -A 10 "dumpPackage|getPackages" src/bin/pg_dump/pg_dump.c

# Look for dependency setup in package initialization
rg -B 5 -A 10 "pkginfo\[i\].dobj.objType = DO_PACKAGE" src/bin/pg_dump/pg_dump.c

474-476: LGTM! Verify package ACL handling

The addition of PACKAGE and PACKAGES types to the ACL parsing logic is correct and follows the existing pattern.

Run the following script to verify that all package-related ACL items are handled consistently:

#!/bin/bash
# Description: Verify that package ACLs are handled consistently across the codebase
# Test: Search for other ACL-related code that might need similar package support

# Check for any ACL-related functions that might need package support
rg -A 5 "case.*when.*type.*=.*'FUNCTION'" 

# Check for any direct package privilege checks
rg -A 5 "(PACKAGE|PACKAGES).*privilege"

#!/bin/bash
# Let's try a broader search for ACL-related code patterns

# Search for ACL parsing and privilege-related code
rg -i "acl.*package" -A 5

# Search for type comparisons in ACL context
rg "strcmp.*type.*FUNCTION" -A 5

# Look for privilege-related code mentioning packages
rg -i "privilege.*package" -A 5

# Search for package-related definitions or constants
rg "define.*PACKAGE" -A 2

1016-1016: LGTM! File ends with a newline

The addition of a newline at the end of the file follows good file formatting practices.

643-646: LGTM! Verify parameter handling in ProcedureCreate

The addition of new parameters to ProcedureCreate is consistent with the implementation pattern.

Run the following script to verify the parameter handling:

#!/bin/bash
# Description: Verify that the new parameters are handled consistently
# Test: Search for other ProcedureCreate calls to ensure consistent parameter usage

# Check all ProcedureCreate calls
ast-grep --pattern 'ProcedureCreate($$$)'

# Check for any related error handling
rg -A 5 "ProcedureCreate.*NULL"

#!/bin/bash
# Search for ProcedureCreate function calls and their parameters
rg -A 5 "ProcedureCreate\(" src/backend/catalog/

# Search for ProcedureCreate function definition to understand parameter handling
rg -B 5 -A 10 "^ProcedureCreate" src/backend/catalog/

#!/bin/bash
# Get more context around the ProcedureCreate function definition to see all parameters
rg -B 10 -A 30 "^ProcedureCreate" src/backend/catalog/pg_proc.c

# Get the specific commit that introduced these changes
git log -p src/backend/catalog/pg_aggregate.c | grep -A 10 "ProcedureCreate.*NULL"

42-42: LGTM: Variable declaration follows established pattern

The static variable declaration follows the same pattern as other count variables in the file.

146-147: LGTM: Package collection properly integrated

The package collection is correctly integrated into the schema data collection sequence with appropriate logging.

73-73: LGTM: Keywords properly added for package support

The new keywords "body", "packages", and "specification" are:

• Correctly categorized as UNRESERVED_KEYWORD with BARE_LABEL
• Properly placed in alphabetical order
• Appropriately chosen for package-related syntax

Also applies to: 376-376, 478-478

64-64: LGTM: Package priority correctly positioned

The PRIO_PACKAGE priority is appropriately placed after PRIO_CAST and before PRIO_FUNC, ensuring packages are created before their contained functions.

1207-1214: LGTM! Good improvement in type checking.

Using get_func_real_rettype() instead of directly accessing procform->prorettype is a better approach as it properly handles domain types by returning their base types.

Line range hint 1235-1241: LGTM! Proper type validation for operator class options parsing functions.

The type checking for operator class options parsing functions is correct, ensuring they:

1. Return void
2. Take exactly one argument of type internal

Line range hint 1261-1265: LGTM! Comprehensive type validation for various operator class functions.

The type checking is thorough and covers all operator class function types:

• btree comparison functions (must return int4)
• btree sort support functions (must return void)
• btree in_range functions (must return bool)
• btree equal image functions (must return bool)
• hash functions (must return int4/int8)

Also applies to: 1282-1286, 1297-1301, 1317-1321, 1344-1348, 1355-1359

2143-2146: LGTM! Proper support for package-related object types in GRANT commands.

The addition of OBJECT_PACKAGE and OBJECT_PACKAGE_BODY is correct and consistent with Oracle's PL/SQL package support.

25-25: LGTM! Package cache header inclusion is appropriate.

The addition of packagecache.h is correctly placed with other utility includes and is necessary for the new package-related functionality.

Line range hint 853-856: LGTM: Package ACL support added correctly

The package ACL support is properly integrated into the default ACL handling framework, following the same pattern used for other object types.

Line range hint 954-956: LGTM: Package support added to SQL interface

Package support is correctly added to the SQL-accessible version of acldefault(), maintaining consistency with other object types.

887-889: LGTM! Verify describePackages implementation.

The implementation of the \k command for describing packages follows the established pattern used for other similar commands. The code structure and function call pattern are consistent.

Let's verify the implementation of the describePackages function:

#!/bin/bash
# Description: Verify the implementation of describePackages function
# Test: Search for the function definition
ast-grep --pattern 'bool describePackages($pattern, $verbose, $showSystem) {
  $$$
}'

#!/bin/bash
# Search for describePackages function definition
rg -n "describePackages" --type c

# If found, get the context of the function
rg -n "describePackages" --type c -B 5 -A 15

#!/bin/bash
# Get the complete implementation of describePackages function
rg -U "bool\s+describePackages.*?^}" --multiline --type c -A 50

#!/bin/bash
# Get the content of describe.c file around the describePackages function
rg -n "describePackages" src/bin/psql/describe.c -B 5 -A 100

3790-3796: LGTM!

The variable declarations follow the standard pattern used in other similar functions in this file.

3797-3858: ⚠️ Potential issue

Verify SQL query compatibility with older PostgreSQL versions.

The SQL query uses features like LEFT JOIN that need to be verified for compatibility with older PostgreSQL versions supported by this code.

Run this script to check version compatibility:

Additionally, consider adding version checks similar to other functions in this file:

+if (pset.sversion < 140000)
+{
+    char sverbuf[32];
+    pg_log_error("The server (version %s) does not support PL/SQL packages.",
+                 formatPGVersionNumber(pset.sversion, false,
+                                     sverbuf, sizeof(sverbuf)));
+    return true;
+}

646-658: LGTM! Well-structured package completion query implementation.

The SchemaQuery array for packages follows the established pattern and includes proper version checking. The implementation correctly handles quoting of package names and gracefully falls back for older server versions.

1256-1256: LGTM! Appropriate additions to CREATE command options.

The additions of EDITIONABLE, NONEDITIONABLE and PACKAGE to the CREATE command completion options are consistent with the Oracle compatibility features.

Also applies to: 1267-1267, 1272-1272

2828-2828: LGTM! Added PACKAGE to COMMENT ON options.

The addition of PACKAGE to the COMMENT ON command completion options is appropriate and consistent with other object types.

4081-4081: LGTM! Comprehensive updates to privilege-related completions.

The changes properly integrate packages into:

• ALTER DEFAULT PRIVILEGES options
• GRANT/REVOKE completion paths
• Help command completion

Also applies to: 4109-4109, 4135-4136

838-838: LGTM!

The placement of enable_cursor_unname variable is appropriate in the configuration variables section.