On 2022-Feb-04, Swaha Miller wrote: > The POC patch Jim Mlodgenski had on that thread was similar to your > proposed way - modules were rows in pg_namespace, with the addition of > a new column in pg_namespace for the nspkind (module or schema.)
I don't agree that what he proposed was similar to my proposal. The main problem I saw in his proposal is that he was saying that modules would be *within* schemas, which is where I think the whole thing derailed completely. He said: > [ This patch ] [...] allows for 3-part (or 4 with the database name) > naming of objects within the module. He then showed the following example: > CREATE SCHEMA foo; > CREATE MODULE foo.bar > CREATE FUNCTION hello() [...] > SELECT foo.bar.hello(); Notice the three-part name there. That's a disaster, because the name resolution rules become very complicated or ambiguous. What I describe avoids that disaster, by forcing there to be two-part names only: a module lives on its own, not in a schema, so a function name always has at most two parts (never three), and the first part can always be resolved down to a pg_namespace row of some kind. -- Álvaro Herrera 39°49'30"S 73°17'W — https://www.EnterpriseDB.com/ "La conclusión que podemos sacar de esos estudios es que no podemos sacar ninguna conclusión de ellos" (Tanenbaum)
