Re: Modifying and solidifying contrib - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Modifying and solidifying contrib
Date
Msg-id 21804.1170115409@sss.pgh.pa.us
Whole thread Raw
In response to Re: Modifying and solidifying contrib  (Richard Huxton <dev@archonet.com>)
Responses Re: Modifying and solidifying contrib  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
Richard Huxton <dev@archonet.com> 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 TSEARCH.foo() 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*
package-level.

> 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


pgsql-hackers by date:

Previous
From: Richard Huxton
Date:
Subject: Re: Modifying and solidifying contrib
Next
From: "Tom Dong"
Date:
Subject: How to configure Postgres to make it not to use (load) crypto libraries.