There is no intention to implement this in pg-python.
The presence of type annotations provides an opportunity to synthesize function creation. Rather than relying on CREATE FUNCTION SQL scripts, a user/admin may submit an entire Python Module whose (marked) functions will be used to manufacture the necessary catalog changes.
This procedural language implementation encapsulates each SQL FUNCTION in a unique module in order to provide an execution environment consistent with Python modules. In cases where functions have shared dependencies, similar environments, or shallow implementations(one liners), having sets of functions grouped in modules allows an author to eliminate the redundancies. While this is already possible, it is a manual operation that requires the interface (SQL parameters) to be declared far from their implementation. Synthesizing the SQL FUNCTIONs from annotated Python functions and, likely, additional decorators would eliminate that distance.
Having module based storage of functions also encourages offline (no-database) testing of functions. Functions annotated to take Python types (@pytypes no longer required) would not even require mocking of the Postgres module to support analysis. Of course, functions depending on prepared statements (SQL) would need runtime substitutions (mocking) in offline testing.
SELECT py_support.install({schema}::text, {module_name}::text, {module}::text); would have the effect of synthesizing and executing CREATE FUNCTION statements along with the insertion of the module text into a support table.
There is no intention to implement this in pg-python.
The presence of type annotations provides an opportunity to synthesize function creation. Rather than relying on CREATE FUNCTION SQL scripts, a user/admin may submit an entire Python Module whose (marked) functions will be used to manufacture the necessary catalog changes.
This procedural language implementation encapsulates each SQL FUNCTION in a unique module in order to provide an execution environment consistent with Python modules. In cases where functions have shared dependencies, similar environments, or shallow implementations(one liners), having sets of functions grouped in modules allows an author to eliminate the redundancies. While this is already possible, it is a manual operation that requires the interface (SQL parameters) to be declared far from their implementation. Synthesizing the SQL FUNCTIONs from annotated Python functions and, likely, additional decorators would eliminate that distance.
Having module based storage of functions also encourages offline (no-database) testing of functions. Functions annotated to take Python types (@pytypes no longer required) would not even require mocking of the Postgres module to support analysis. Of course, functions depending on prepared statements (SQL) would need runtime substitutions (mocking) in offline testing.
SELECT py_support.install({schema}::text, {module_name}::text, {module}::text);would have the effect of synthesizing and executing CREATE FUNCTION statements along with the insertion of the module text into a support table.