Re: Clarification on when _PG_init() is invoked for extensions
| От | Rahila Syed |
|---|---|
| Тема | Re: Clarification on when _PG_init() is invoked for extensions |
| Дата | |
| Msg-id | CAH2L28tHEjOr5gK187JzKS14uxYWd_S==aRUPE9OQ412yKAsow@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Clarification on when _PG_init() is invoked for extensions (Ayush Vatsa <ayushvatsa1810@gmail.com>) |
| Список | pgsql-hackers |
Hi,
CREATE extension does not automatically load or ensure that _PG_init() is run.
It mainly runs the .sql script in your extension.Thanks for the clarification. However, in my testing,_PG_init()did run when I executedCREATE EXTENSION. I suspect this might be happening because the SQL script defines
C functions usingMODULE_PATHNAME, which triggers the library load.
In a new session,_PG_init()seems to run again when any of those C functions are executed.
You are right, if the create extension creates a C function it triggers the load of the library, which
in turn causes _PG_init() to execute.
Sorry for the confusion.
FWIW, the call stack looks like the following:
_PG_init ()
internal_load_library()
load_external_function ()
fmgr_c_validator ()
FunctionCall1Coll ()
OidFunctionCall1Coll ()
ProcedureCreate ()
CreateFunction ()
ProcessUtilitySlow ()
standard_ProcessUtility ()
ProcessUtility ()
execute_sql_string ()
execute_extension_script ()
CreateExtensionInternal ()
CreateExtension ()
Thank you,
Rahila Syed
in turn causes _PG_init() to execute.
Sorry for the confusion.
FWIW, the call stack looks like the following:
_PG_init ()
internal_load_library()
load_external_function ()
fmgr_c_validator ()
FunctionCall1Coll ()
OidFunctionCall1Coll ()
ProcedureCreate ()
CreateFunction ()
ProcessUtilitySlow ()
standard_ProcessUtility ()
ProcessUtility ()
execute_sql_string ()
execute_extension_script ()
CreateExtensionInternal ()
CreateExtension ()
Thank you,
Rahila Syed
В списке pgsql-hackers по дате отправления: