Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> 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.
Right. We've looked into that before --- when I made pg_namespace,
I called it that because I thought we might be able to support
nested namespaces --- but it'd really create a mess. In particular,
the SQL standard says what a three-part name means, and this ain't it.
If we invent modules I think they need to work more like extensions
naming-wise, ie they group objects but have no effect for naming.
Alternatively, you could insist that a module *is* a schema for naming
purposes, with some extra properties but acting exactly like a schema
for naming. But I don't see what that buys you that you can't get
from an extension that owns a schema that contains all its objects.
On the whole I'm kind of allergic to inventing an entire new concept
that has as much overlap with extensions as modules seem to. I'd
rather try to understand what functional requirements we're missing
and see if we can add them to extensions. Yeah, we won't end up being
bug-compatible with Oracle's feature, but that's not a project goal
anyway --- and where we have tried to emulate Oracle closely, it's
often not worked out well (poster child: to_date).
regards, tom lane
