Richard Huxton <> writes:
> Tom Lane wrote:
>> Wouldn't it be a whole lot easier just to drive it off schema, rather
>> than inventing duplicative parallel infrastructure?

> Four differences:
> 1. You couldn't have a tsearch package with functions in public. At 
> least not without some IMPORT INTO public

So?  That's what a search path is for.

> 2. You can't easily disable access to a whole package if it's spread 
> over multiple schemas.

The main reason I can see for separating a package into more than one
schema is exactly that some parts would be "public" and others
"private".  So schema-level access controls are what you want, *not*

> 3. You can't determine what package various objects belong to - is this 
> "stopwords" table from tsearch2 or ArchonetSearch17?

Sure you can; you look to see what schema it's in.

> 4. You can't have one package depending upon another (webstats v2.1 
> depends on internet_addr v2.3).

What's that have to do with it?  Perhaps I should be clearer: I agree
with having an explicit representation of a package in some new system
catalog for that purpose.  That does not translate to needing to add
package hooks to every other catalog.  Indirect links through schemas
seem more than sufficient.

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?


Reply via email to