Hi Jeff, On Wed, Jun 12, 2024 at 3:07 AM Jeff Davis <pg...@j-davis.com> wrote: > > On Tue, 2024-06-11 at 15:24 +0530, Ashutosh Sharma wrote: > > 3) When the ALTER EXTENSION SET SCHEMA command is executed and if the > > function's search_path contains the old schema of the extension, it > > is > > updated with the new schema. > > I don't think it's reasonable to search-and-replace within a function's > SET clause at ALTER time. > > I believe we need a new special search_path item, like > "$extension_schema", to mean the schema of the extension owning the > function. It would, like "$user", automatically adjust to the current > value when changed. > > That sounds like a useful and non-controversial change.
I've definitely thought about it, and I agree that this approach could help simplify things. However, we do have some challenges with the resolution of $extension_schema variable compared to $user. Firstly, we need something like CurrentExtensionId to resolve $extension_schema, and we need to decide where to manage it (CurrentExtensionId). From what I understand, we should set CurrentExtensionId when we're getting ready to execute a function, as that's when we recompute the namespace path. But to set CurrentExtensionId at this point, we need information in pg_proc to distinguish between extension-specific and non-extension functions. If it's an extension specific function, it should have the extension OID in pg_proc, which we can use to find the extension's namespace and eventually resolve $extension_schema. So, to summarize this at a high level, here's is what I think can be done: 1) Include extension-specific details, possibly the extension OID, for functions in pg_proc during function creation. 2) Check if a function is extension-specific while preparing for function execution and set CurrentExtensionId accordingly. 3) Utilize CurrentExtensionId to resolve the namespace path during recomputation. 4) Above steps will automatically repeat if the function is nested. 5) Upon completion of function execution, reset CurrentExtensionId to InvalidOid. I think this should effectively tackle the outlined challenges with resolution of $extension_schema during namespace path recomputation. What are your thoughts on it? Thanks, -- With Regards, Ashutosh Sharma.