Tom Lane wrote:
Richard Huxton <email@example.com> writes:
1. Add a new column for all system objects, separate from schema:
Wouldn't it be a whole lot easier just to drive it off schema, rather
than inventing duplicative parallel infrastructure? That is, say that a
package has one or more schemas and what it "owns" is whatever is in
those schemas. This lets you, for example, use schema permissions to
manage access to the package.
1. You couldn't have a tsearch package with functions in public. At
least not without some IMPORT TSEARCH.foo() INTO public
2. You can't easily disable access to a whole package if it's spread
over multiple schemas.
3. You can't determine what package various objects belong to - is this
"stopwords" table from tsearch2 or ArchonetSearch17?
4. You can't have one package depending upon another (webstats v2.1
depends on internet_addr v2.3).
With the current search_path functionality I think it's important the
package names are separate. I think I'm right in saying there are two
packaging schemes out there - you either have a single hierarchy
(Perl/Java) or something parallel (at 90 degrees to?) to an existing
setup (RPM/deb). I think our search_path means we're dealing with
something more like a Linux packaging setup.
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend