Wrapping or obfuscating PL/pgSQL code in PostgreSQL is typically done to conceal the logic of stored procedures, functions, or triggers from end-users or administrators who have access to the database. PostgreSQL does not provide a built-in feature specifically for wrapping or obfuscating PL/pgSQL code, as it's generally designed to be an open system. However, there are some approaches you can use to achieve a level of code hiding:

1. Using Security Definer Functions

• You can create functions with the SECURITY DEFINER attribute. This allows the function to run with the privileges of the user who defined it, not the user who invokes it. This way, you can restrict access to the underlying logic and data the function accesses.

  CREATE FUNCTION my_function() RETURNS void LANGUAGE plpgsql SECURITY DEFINER AS $$
  BEGIN
    -- Function logic here
  END;
  $$;
  
  

• Make sure to properly manage privileges to ensure security.

2. Storing Encrypted Code in an External Application

• Write the logic in an external application in a language like Python or Java, where you can encrypt or obfuscate the code. Then, have the application connect to PostgreSQL and execute the logic.
• This method means the logic is never stored as plaintext in the database, but it does add complexity and requires an external application to manage.

3. Using External PL Languages

• Use a procedural language other than PL/pgSQL, such as PL/Python or PL/Java, which might offer more sophisticated ways to obfuscate code. However, this also adds the overhead of managing another language environment in your database.

4. Custom Obfuscation Scripts

• Write a custom script to obfuscate your PL/pgSQL code before loading it into the database. This could involve renaming variables, removing comments, or other simple text transformations. However, be aware that such obfuscation is usually not very secure against determined reverse engineering.

5. Binary Stored Procedures (Not Native in PostgreSQL)

• Some database systems support stored procedures compiled into binary format, but PostgreSQL does not support this natively.

6. Access Control

• Ensure strict access control to the database. Restrict who can view the function definitions in the pg_proc table. This is more about controlling access than obfuscating code but is an essential part of protecting your database logic.

Considerations

• Performance: Some obfuscation methods might impact the performance of your functions.
• Maintenance: Obfuscated code can be much harder to debug and maintain.
• Security: Relying on obfuscation for security is not recommended. It's better to implement robust access controls and encryption for sensitive data.

Conclusion

True code wrapping or obfuscation in PostgreSQL, especially at the database level, is limited. The best approach often involves a combination of access controls, using external applications for critical logic, and possibly custom obfuscation scripts. Always consider the trade-offs in terms of performance, maintainability, and actual security benefits.