Jim Mlodgenski <jimmy76@gmail.com> writes:
> Questions
> - Do we want to add module support?
Certainly many people have asked for that, or things like that.
> - If we do, should it be implemented as a type of namespace or should it
> be its own object type that lives in something like pg_module?
While I didn't read the actual patch, your sketch just above this makes
me want to run away screaming. In the first place, what do you think
the primary key of pg_namespace is now? But the bigger problem is that
sub-namespaces just do not work in SQL syntax. Back when we first added
schema support, I had some ambitions towards allowing nested schemas,
which is a big part of the reason why pg_namespace is named that and not
pg_schema. But the idea fell apart after I understood the syntactic
ambiguities it'd introduce. It's already quite hard to tell which part
of a multiply.qualified.name is which, given that SQL says that you can
optionally put a "catalog" (database) name in front of the others.
I really doubt there is a way to shoehorn sub-schemas in there without
creating terrible ambiguities. Is "a.b.c" a reference to object c in
schema b in database a, or is it a reference to object c in sub-schema b
in schema a? This is why we've ended up with bastard syntax like
(table.column).subcolumn.
> - How should users interact with objects within a module? They could be
> mostly independent like the current POC or we can introduce a path like
> ALTER MODULE foo ADD FUNCTION blah
I wonder whether it'd be better to consider modules as a kind of
extension, or at least things with the same sort of ownership relations
as extensions have.
regards, tom lane