On Thu, Jun 3, 2021 at 8:49 AM Peter Eisentraut <peter.eisentr...@enterprisedb.com> wrote: > Given that, as you said, the concept of modules is in the SQL standard, > there is surely some guidance in there about how this is supposed to > affect name resolution. So let's start with that. Maybe we won't like > it in the end or whatever, but we should surely look there first.
Studying the spec further, catalog/schema/module are all used to identify a module-level routine. I don't see it spelled out that is needs to be in that format of catalog.schema.module.routine to fully qualify the routine, but it would likely be awkward for users to come up with an alternative syntax like (catalog.schema.module).routine or catalog.scheme.module->routine The way the spec is worded, I read it as that schemas take precedence over modules regarding path resolution. So for example with 2-level naming if there is a schema 'foo' and a module 'public.foo' both with functions 'bar' 'foo.bar' would refer to the schema-level function not the module-level function. I've not found guidance on throwing catalog into the mix and 3-level naming. Say we had a catalog 'postgres' with a schema 'foo' with a function 'bar' and a schema 'postgres' with a module 'foo' with a function 'bar'. What would 'postgres.foo.bar' refer to? If the SQL was executed from a catalog other than 'postgres', we'd have no way of knowing if 'foo.bar' existed there. So if it's implementation dependent, saying schemas take precedence over catalogs may make sense and 'postgres.foo.bar' refers to the module-level function in the 'postgres' schema.
